MCP Is Not a Standard Yet. It Is a Conversation.

Model Context Protocol – MCP – is the most useful working agreement to emerge from the agentic tooling space in the last two years. We use it. We build for it. We have shipped MCP servers in production. We think it is a net good for the ecosystem.

We also think the industry conversation around MCP has gotten ahead of what MCP actually is. The protocol is being treated as a settled standard. It is not. It is a working conversation between a handful of model providers, IDE vendors, and tool builders, evolving in public, with breaking changes still landing in the spec, the SDKs, and the runtime expectations. Treating it as TCP/IP – as a stable layer you build long-lived infrastructure on – is going to disappoint a lot of teams over the next eighteen months.

What MCP Got Right

The protocol solved a coordination problem that was actively burning engineering time across the industry. Before MCP, every agentic tool integration was bespoke. A team building an agent that needed to call a custom internal API wrote a custom function-calling shim, a custom argument schema, a custom auth flow, a custom error format, and a custom way to thread tool output back into the conversation. Doing this for one tool was fine. Doing it for ten was tedious. Doing it for fifty, in a way that survived a model swap or a framework upgrade, was infrastructure work.

MCP standardized the shape of the integration. A tool is a thing with a name, a schema, an invocation contract, and a transport. A model is a thing that consumes tools through a standard interface. The transport between them is defined. The boilerplate is, finally, boilerplate – which means it can be generated, libraried, and forgotten about.

This is the part that worked. MCP made it cheaper to expose a tool to an agent than to keep tools locked inside agent-specific harnesses. Anything that lowers the friction of shipping a tool gets more tools shipped. The ecosystem has more tools because MCP exists.

What MCP Has Not Yet Settled

The parts of the protocol that are still actively being negotiated are the parts that matter most for production use.

Authentication. The first stable versions of MCP under-specified auth. The current revision has more on the topic, but in practice each tool provider has implemented something slightly different – bearer tokens, OAuth flows, signed requests, environment-variable secrets. Building a tool that works against the auth assumptions of any client is still a per-client integration exercise. The protocol calls for a contract; the ecosystem has not yet agreed on which contract.

Long-running operations. MCP is, fundamentally, a request-response protocol. Tool calls return. They return synchronously or with simple streaming. Real production tools frequently have operations that take minutes or hours – training a model, running a migration, indexing a corpus. The pattern for representing those operations as MCP tools is not settled. Some implementations use job IDs and a poll-status tool; some return long streams; some block. None are wrong. None are interoperable.

Tool composition. Agents that need to chain tools together are doing so above the MCP layer, in the orchestration code. There is no canonical way for an MCP server to express that tool A is the right precursor to tool B, or that they should be called in a specific order, or that there is a shared session state between them. Each agent framework has its own conventions. The protocol does not yet have an opinion.

Error semantics. Tool errors are returned as strings. Whether the agent treats a particular error as fatal, retryable, or a signal to ask the user is policy that lives outside the protocol. Two well-built MCP servers can return errors in two completely different shapes for the same underlying condition, and the agent has to disambiguate. This is not unworkable, but it is not a settled standard.

Versioning and capability negotiation. Tools evolve. Their schemas change. Their behavior changes. There is currently no canonical way for an MCP server to advertise the version of a tool, the breaking changes between versions, or the migration path for clients. Most production deployments are pinning specific server versions and treating upgrades as a manual integration event. This is the opposite of a stable standard.

None of these is a fatal flaw. All of them will get worked out. The point is that they have not been worked out yet, and a system built today on MCP is a system that will need to absorb breaking changes as the protocol matures.

What Production Use Looks Like Right Now

Production MCP use in our own systems looks like the following.

We pin SDK versions on both the server and client sides, and treat SDK upgrades as planned events with a regression check. The SDKs are still landing breaking changes at a cadence that does not yet match a “stable standard.”

We wrap MCP servers in a thin adapter layer that owns auth, retry, error normalization, and timeout policy. The adapter layer is what the rest of our agent code talks to. When MCP itself revises its conventions, we update the adapter. The agents do not know.

We build internal MCP servers when the tool is internal and we control both ends. We use third-party MCP servers when the convenience outweighs the version-stability cost. We do not build long-lived production infrastructure that assumes the third-party server’s contract is permanent.

We document every MCP integration as if it were a private API, not a standard. The integration assumes a specific server version, a specific transport, and a specific behavior under failure conditions. When any of those changes, the integration is re-validated. This is more work than treating MCP as a stable protocol, and it is the right amount of work given where the protocol actually is.

The Hype Pattern

The pattern we have seen too often is the one that has played out with every emerging protocol for the last forty years. A reasonable working agreement gets adopted by a few major players. Press coverage promotes it from “working agreement” to “standard.” Procurement teams and architecture review boards start writing it into requirements documents. Vendors start advertising “MCP compatibility” as a checkbox. The market enters a phase where the badge of conformance matters more than what is actually shipping under the badge.

This phase is bad for the protocol. It freezes the conversation prematurely. Decisions that should have stayed open for another revision cycle get baked into vendor implementations that nobody wants to break. The protocol stops evolving because the ecosystem cannot absorb more change. What gets standardized is the version that was current at peak hype, which is rarely the version that was best.

We are watching this happen with MCP now. The protocol deserves another year or two of honest revision. The press cycle is not going to give it that.

How We Recommend Treating MCP

A practical posture for engineering teams working with MCP in 2026:

Adopt it. The benefits over the bespoke-integration baseline are real. Building tools in MCP is faster than not. You should do it.

Do not treat it as settled. Plan for SDK upgrades. Plan for protocol revisions. Wrap integrations in adapters you control. Pin versions on both sides. Test upgrades as you would test any external dependency upgrade, not as you would test a TCP/IP socket call.

Push back on “MCP-compatible” as a procurement requirement. Compatibility today does not mean compatibility tomorrow. A vendor that ships against the current SDK has done something useful. A vendor that promises forward-compatibility with the protocol-as-standard is making a promise they cannot keep, because the protocol-as-standard does not exist yet.

Contribute. The protocol is being shaped by the projects that show up in the issue tracker and the SDK PRs. If you have built MCP servers in production and have opinions on auth, long-running operations, error semantics, or any of the other open questions, the right place to express them is in the upstream conversation, not in a blog post. (Including this one. Hello.)

The Honest Statement

MCP is the best working agreement the agentic tooling space has produced. It is not a standard yet. The conversation is healthy, the trajectory is good, and the protocol will mature.

In the meantime, build accordingly. Use MCP. Wrap it. Version it. Re-validate on upgrade. Resist the procurement and press-cycle pressure to treat the current revision as a settled contract. Treat it for what it is: a conversation that is going somewhere good, that has not arrived yet.