DEV Community: Mark Fussell

MCP Is the WSDL Moment for Agents

Mark Fussell — Tue, 27 Oct 2026 03:26:59 +0000

Web services standardised how to describe a service, then spent a decade learning that identity, reliability and recovery don't belong in the message format. MCP's maintainers have learned that lesson. Every team running an MCP server still has to.

In 2001 the W3C published WSDL, the Web Services Description Language. A WSDL file described what a service could do: its operations, its message formats and where to send them. Feed it to a tool and you got a working client. Two companies that had never met could integrate in an afternoon. I was at Microsoft through those years and was fully engaged in the WS-* specification standards bodies, and the excitement was real.

The Model Context Protocol does the same job for agents. An MCP server wraps a database, an API or a file system and tells any MCP client which tools it has, what arguments each takes and what it returns. Messages are JSON-RPC 2.0, over STDIO on the same machine or Streamable HTTP across a network. Write the server once and every MCP-compatible agent can use it. That removes the M-by-N problem function calling left us with, where M AI applications and N tools meant wiring each pair by hand.

So far, so WSDL. Here is where I think the story diverges: MCP will win where WSDL didn't, because it is choosing to stay thin. That puts the hard problems somewhere else, and anyone shipping an MCP server has to decide where.

What description didn't cover

Describing a service turned out to be the easy part. Once WSDL made integration cheap, everyone asked the next questions. Who is allowed to call this operation? What happens if the call is delivered twice? What if the caller crashes halfway through a five-step exchange? How do I find out what happened?

The industry answered by writing more specifications: WS-Security, WS-ReliableMessaging, WS-AtomicTransaction, WS-Coordination and a long tail after them. I was in the standards bodies for all of these, implementing them in Microsoft products. Each was reasonable on its own. Together they made a stack few teams could implement and fewer could debug. It was a specification nightmare that only Microsoft and IBM could afford to do. The public UDDI registries, meant to be the directory of every web service on earth, were switched off in 2006.

REST and JSON won the next decade by doing less and not having the insane complexity that WS-* involved. The hard problems moved out of the message format and into the runtime, which is where they belonged from the start: API gateways, service meshes, retry policies, mutual TLS and distributed tracing. And of course the Dapr project.

MCP chose the REST path

The clearest sign is the 2026-07-28 revision of the Model Context Protocol, the largest since launch. Its direction is the opposite of WS-*: it takes things out.

No more sessions. The initialize handshake and the Mcp-Session-Id header are gone. Every request carries its own protocol version and client capabilities, so any server instance can handle any call behind a plain load balancer.
State moves to the application. A server that needs continuity hands the model an explicit handle, a basket ID or a browser ID, and gets it back as an ordinary argument on the next call.
Less in the core. Tasks, the long-running work feature, moved out of the core spec into an opt-in extension. Roots, Sampling and Logging are deprecated, with OpenTelemetry named as the home for observability.
Built for infrastructure. New Mcp-Method and Mcp-Name headers let gateways route and rate-limit without reading the body, and W3C Trace Context in the request metadata lets traces follow a tool call end to end. We applied exactly the same approach in Dapr.

That is the REST lesson applied on purpose: the protocol defines the contract, and the infrastructure around it does the rest. New capabilities now arrive as extensions that are negotiated and versioned separately, rather than as specs every implementation must carry. WS-* never had that release valve. Whether extensions stay optional is the thing to watch.

What every MCP server in production still has to answer

A thinner protocol doesn't make the WSDL-era questions go away. It hands them to you.

Who may call which tool. The spec now treats an MCP server as an OAuth 2.1 resource server, which settles how a client proves who it is. It doesn't decide which of a server's forty tools that client may invoke, or where the upstream API key for your CRM lives. Too often that key still sits in agent code or an environment variable.

What the tool says it does. A tool description is text the model reads as instruction. Security teams spent 2026 warning about tool poisoning, where a description is altered after approval to steer an agent into leaking data. Nothing in the protocol stops a server from changing what it tells the model.

What happens on failure. Picture an agent that calls a refund tool, then crashes before recording the result. It restarts and sees an unfinished task. Does it refund again? A stateless protocol is the right design, but it means the answer lives entirely in your application. Retries, timeouts and circuit breakers are yours too.

Which servers to trust. The official MCP Registry is thriving where UDDI died, with roughly 39,000 servers listed by early October. But a registry is a namespace, not a trust decision. Choosing which MCP server your agents may reach is still a runtime question, and it is critical to security.

Where the answers belong

The runtime around the MCP server is the right home for each of those questions:

Identity comes from the platform, with deny-by-default rules per tool.
Credentials are injected at request time, if they're needed at all once identity is federated, and never sit in the agent.
Retries and timeouts are policy, written once, not code in every application.
Each tool call is recorded as a step in a durable workflow, so an agent that crashes after the refund resumes past it instead of making it twice.

A wave of MCP gateways now handles the first three, and that instinct is right. But a gateway sees a request, not the workflow it belongs to. Recovering from a crash means the call has to be recorded somewhere that outlives the agent process.

That is the approach we took with Diagrid Catalyst. It fronts MCP servers with proxy endpoints that speak Streamable HTTP and the stateless 2026-07-28 revision, so off-the-shelf clients and agent frameworks work unchanged. Authentication, credential injection and per-tool access rules happen outside the agent, and every tool call runs as a durable workflow step. Dapr does the same for everything else the agent touches: state, messaging and service calls.

The thin protocol wins

I expect the model context protocol to become as universal as WSDL wanted to be, because it is staying as thin as WSDL should have. MCP servers will number in the hundreds of thousands, and the engineering that decides whether they are safe to run will happen around them.

If you're building an MCP server this quarter, decide now where its caller identity, credentials, retries and crash recovery come from. The spec won't decide it for you, and its maintainers have made clear it shouldn't.

A longer explainer on how MCP works, with the architecture: Model Context Protocol (MCP) Explained.

Sources

The 2026-07-28 MCP Specification Release Candidate, MCP blog
MCP 2026-07-28 stable release, GitHub
MCP adoption statistics (registry count, October 4, 2026)
MCP tool poisoning research note, Cloud Security Alliance

The Saga Pattern Was a Workaround

Mark Fussell — Fri, 09 Oct 2026 17:33:44 +0000

We spent a decade hand-building compensation logic because our runtimes couldn't remember where they were. Now they can.

The saga pattern is older than most of the systems it runs in. Hector Garcia-Molina and Kenneth Salem published it in 1987 for long-lived database transactions. The microservices era rediscovered it around 2015, and I spent a good part of the following decade explaining it on stage: when a business transaction spans services and step four fails, you can't roll back a distributed system, so you run compensating actions (refund the charge, release the inventory, cancel the booking) in reverse order.

What is the saga pattern?

A saga is a sequence of local transactions in which every step has a defined compensating action. If a step fails, the saga runs the compensations for every step that already completed. It trades the atomicity you lost when you distributed the system for eventual consistency that you manage yourself.

What a saga really is

Sagas work. Payment, travel, and retail systems run on them today. But be honest about what a saga actually is: a hand-built answer to the question "what happens when the process dies halfway through?"

To answer it, you maintain four things:

Compensation logic for every step
A state machine that tracks which step you're on
Recovery code that reads that state after a crash
Idempotency so a retried compensation doesn't fire twice

Every team builds this machinery, slightly differently, with the same bugs.

What durable execution changes

We built sagas this way because the runtime gave us nothing better. That premise has expired.

Durable execution journals every step as it runs. A crash resumes from the exact step that failed, completed steps never re-execute, and compensation becomes ordinary workflow code: recorded, replayable, and visible, instead of tribal machinery around the edges. The state machine you used to maintain by hand is now the engine.

Sagas don't disappear. The business reality they encode (some actions can only be undone, not prevented) is permanent. What disappears is the plumbing. On a durable workflow runtime, a saga is a dozen lines:

def order_saga(ctx: wf.DaprWorkflowContext, order):
    compensations = []
    try:
        yield ctx.call_activity(reserve_inventory, input=order)
        compensations.append(release_inventory)

        yield ctx.call_activity(charge_payment, input=order)
        compensations.append(refund_payment)

        yield ctx.call_activity(book_shipping, input=order)
    except Exception:
        for undo in reversed(compensations):
            yield ctx.call_activity(undo, input=order)
        raise

Try the steps, catch the failure, run the compensations, all of it journaled. One of my favourite demos is deleting two-thirds of a team's saga code and watching the remaining third become readable.

Why agents raise the stakes

Agents make all of this matter more. An agent's compensations guard real money and real customer data. Its steps are expensive LLM calls you'd rather not re-run. And its failure points multiply with its autonomy: an agent that books a flight, charges a card, and then fails to reserve the hotel needs to unwind cleanly, not leave a customer half-booked.

If sagas were worth teaching through a decade of microservices, their durable-execution successor is worth learning in the first year of agents.

Further reading:

Strip the Branding Off Your Agent Framework. It's the Same Five Lines.

Mark Fussell — Wed, 30 Sep 2026 13:00:00 +0000

Strip the branding off your sgent framework and it's the same five lines.

This will annoy some framework authors, so let me be clear about the claim. Take LangGraph, CrewAI, Strands, Google ADK, Pydantic or Microsoft Agent Framework. Remove the branding, the abstractions, the graph builders. At the core of every one of them you find variations of this:

while not goal_reached(history):
    thought = llm(history)       # decide
    action  = parse(thought)     # choose a tool
    result  = execute(action)    # the side effect happens HERE
    history.append(result)       # remember

Five lines of code. The model is almost comically simple, and I mean that as a compliment, because simple models win. The Windows message loop (GetMessage, TranslateMessage, DispatchMessage) was about this same size. I wrote those for Windows 3.0 back in the 90s, so the shape is an old friend.

Before the objections arrive: parallel tool calls just make action a list. Graph-based frameworks turn the while into edges between nodes. Multi-agent setups are loops calling loops. The shape holds.

So why do agent frameworks feel different? Because they compete on everything around the loop: nicer tool definitions, multi-agent hand-offs, streaming, tracing. All genuinely useful, and all decoration on the same five lines. It is still a loop.

The line that matters

Whether your agent survives production isn't decided by the loop or the decoration. It's decided by line four. execute(action) is where money moves, tickets open and emails get sent.

When the process dies mid-loop (a deploy, an eviction, an OOM kill), someone has to answer two questions: which steps already completed, and where should we resume? The loop has no idea. Agent framework checkpoints help, but they snapshot state at intervals, so recovery often means rerunning work since the last snapshot, including side effects that already fired. No frameworks have a failure detection mechanism included, which is the really hard problem to solve.

That's a runtime concern, and it has a name: durable execution. Here's the same loop on a durable runtime, in engine-agnostic pseudocode:

@workflow
def agent(ctx, goal):
    history = [goal]
    while not goal_reached(history):
        thought = yield ctx.step(llm, history)      # journaled
        action  = parse(thought)                    # deterministic, safe to replay
        result  = yield ctx.step(execute, action)   # journaled, retried if in flight
        history.append(result)

Each completed step is recorded in a journal. After a crash, the runtime replays the journal. Completed steps return their recorded results instantly, with no second LLM bill and no duplicate email, and execution resumes at the exact step that was in flight.

One honest caveat: a step that crashes after its side effect fires but before the journal write will be retried. Durable execution gives you at-least-once steps, not magic. So your tools still need to be idempotent (pass an idempotency key to the payment API). The difference is that retries become precise and bounded instead of "rerun everything and hope."

The corollary

If the loop is the same five lines everywhere, durability doesn't need to live in the framework. Keep the framework you like, and put the loop on a durable runtime. These are separable decisions, and the ecosystem is already heading that way, with durable-runtime integrations appearing for several popular frameworks.

I'd go further: coupling the two is how the industry gets locked in for the next decade. This is workflow orchestration's oldest lesson wearing a new AI badge.

I've written the longer history of where this loop came from in chapter 6 of my series, and there's a practical companion on keeping your framework while adding durable execution.

Disagree? Tell me which framework's core loop is genuinely a different shape. I'll happily be wrong.