MCP Is the WSDL Moment for Agents

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