MCPx

A reliability runtime for consequential WebMCP workflows, giving AI agents durable execution, uncertainty-aware recovery, and human-approved compensation across web applications.

Comment

Inspiration

While building with WebMCP, I kept thinking about one question:

What happens if an agent performs an action, the application successfully makes the change, but the response never gets back to the agent?

For example, imagine an agent creates a routing rule. The route is successfully created, but the acknowledgement gets lost.

From the agent's point of view, it looks like the request failed.

But did it actually fail?

If the agent simply retries, it could create the same resource twice. If it assumes the action worked, it could continue a workflow based on something that may not exist.

The problem gets even harder when an agent is working across several applications. Maybe the first three actions succeed and the fourth fails. Now you have resources left behind and someone has to figure out what actually happened.

That was the idea behind MCPx.

WebMCP makes structured agent actions possible. MCPx makes those actions reliable.

What it does

MCPx is a reliability runtime for multi-step WebMCP workflows.

The main idea is simple. For consequential actions, MCPx thinks about three things:

Execute → Inspect → Compensate

For example:

create_route → get_route → delete_route

Execute performs the action.

Inspect asks the application for the actual state of that action.

Compensate provides a way to safely undo it if the larger workflow fails.

This becomes especially useful when something goes wrong after an action has already been sent.

Instead of immediately assuming failure, MCPx can put the operation into an explicit state called IN_DOUBT.

It then asks the application that owns the resource for ground truth.

If the resource actually exists:

IN_DOUBT → RECONCILING → RECOVERED

The workflow continues without blindly performing the original mutation again.

If something later fails for certain, MCPx stops the workflow and asks the human operator before performing destructive rollback.

Once approved, it compensates the completed operations in reverse dependency order and checks each application again to confirm that the resources created by that transaction are gone.

Why WebMCP?

This is where WebMCP became particularly interesting to me.

The applications involved in a workflow should remain the source of truth for their own resources.

MCPx should not need direct access to every application's database just to determine whether an operation succeeded.

Instead, each application can expose structured capabilities through WebMCP.

In MCPx, the reference applications register tools using:

document.modelContext.registerTool(...)

The MCPx Browser Runner discovers tools from the authorized applications using:

document.modelContext.getTools({ fromOrigins: [...] })

It then executes the native browser tools through:

document.modelContext.executeTool(...)

So MCPx coordinates the workflow, while each WebMCP application still owns and understands its own state.

That separation is a big part of the project.

The demo

I built a four-step reference workflow to show what happens when things don't go perfectly:

Database → Compute → Routing → Frontend

Database succeeds.

Compute succeeds.

Routing is where things get interesting.

For the demo, I intentionally inject an acknowledgement-loss fault after the Routing service commits its resource.

MCPx doesn't know yet whether the write happened, so Routing becomes IN_DOUBT.

Instead of blindly calling create_route again, MCPx calls get_route.

The Routing application confirms that the route actually exists, so MCPx marks the operation RECOVERED and continues.

Then Frontend deliberately rejects before committing its operation.

This is a confirmed failure, so the transaction stops in AWAITING_COMPENSATION_APPROVAL.

The human operator can see what happened and approve the rollback.

MCPx then compensates:

Routing → Compute → Database

After every compensation, it calls the application's inspection tool again to verify that the resource created by this transaction is actually absent.

The transaction finally reaches COMPENSATED.

Humans and agents working together

I didn't want MCPx to become another AI agent.

I wanted it to solve a different problem.

The way I think about the architecture is:

The agent decides what should happen.

The human controls important safety boundaries.

MCPx makes sure the multi-step operation is executed reliably.

WebMCP gives MCPx structured capabilities to work with across the applications.

To test that idea outside the MCPx dashboard, I integrated MCPx with FileFlow, a distributed file-processing project I had already built.

During the challenge, I extended FileFlow with an AI Operations Agent.

The agent can observe real information about the FileFlow pipeline, including queue state, worker heartbeat and failed jobs.

For low-risk situations, such as an eligible failed job, the agent can take a bounded recovery action itself.

But when it wants to perform a consequential multi-service workspace operation, it asks for human confirmation and then delegates the actual workflow to MCPx through @mcpxx/sdk.

That separation became one of my favourite parts of the project:

the agent doesn't need to reinvent retries, reconciliation, rollback and transaction durability every time it wants to do something consequential.

How I built it

MCPx is a TypeScript monorepo containing:

  • a Next.js coordinator and control plane
  • a browser WebMCP Runner
  • a PostgreSQL-backed transaction and event ledger
  • a DAG workflow engine
  • execute / inspect / compensate reliability contracts
  • explicit IN_DOUBT, RECONCILING and RECOVERED states
  • human-approved compensation
  • post-compensation verification
  • four independent WebMCP reference applications
  • the @mcpxx/sdk package for external applications and agents

One architectural rule was particularly important to me:

MCPx should not secretly bypass WebMCP for the actual reference-service mutations.

The SDK can submit a workflow to the MCPx coordinator, but the work waits for an active browser runner.

The Browser Runner discovers the appropriate WebMCP tool from the application's origin and executes it through the browser.

The result is then reported back to the durable coordinator.

Challenges I ran into

One of the hardest bugs came from RegisteredTool.

At first, it seemed reasonable to discover a WebMCP tool, store it and execute it later.

That didn't work.

A native RegisteredTool contains browser-owned context associated with the page or frame that registered it. Treating it like normal serializable data caused execution to fail.

The solution was to store only the tool's metadata.

When MCPx actually needs to execute something, the Browser Runner discovers the tools again and passes the fresh native RegisteredTool directly to executeTool(...).

Another challenge was changing how I thought about failure.

I initially thought mostly in terms of success and failure. But after a request has been dispatched, there is a third possibility:

we simply don't know yet.

That is why IN_DOUBT became such an important state in MCPx.

The final challenge was rollback.

Calling a delete operation isn't enough to prove cleanup happened. MCPx therefore inspects the owning application after compensation and only considers that step compensated when the resource is confirmed absent.

What I learned

The biggest thing I learned from building MCPx is that reliable agent systems need to be comfortable saying:

"I don't know what happened yet."

Agents are getting much better at deciding what actions to take.

But once those actions have real side effects across multiple applications, another set of problems appears: partial success, lost acknowledgements, duplicate operations, recovery and cleanup.

I don't think every AI agent should have to solve those problems itself.

MCPx is my exploration of what a reusable reliability layer for consequential WebMCP workflows could look like.

Challenge work disclosure

MCPx was built from scratch during the WebMCP Challenge.

This includes the coordinator, Browser Runner, transaction engine, reliability contracts, WebMCP reference applications, control plane and @mcpxx/sdk.

FileFlow existed before the challenge and is used here as an external application consuming MCPx.

During the challenge, I extended FileFlow with its AI Operations Agent, MCPx SDK integration, human approval flow, real-time MCPx transaction visualization, rollback approval and links into the MCPx control plane.

Built With

Share this project:

Updates

Submission history