Writing
Open Standards Outlive Model Generations
A year after the MCP bet, the argument can be checked against what happened rather than what was hoped.
Writing
A year after the MCP bet, the argument can be checked against what happened rather than what was hoped.
Notes
A year ago, I wrote that MCP might matter more than another model release.
At the time, that was mostly an architectural bet. Model Context Protocol was only days old. Anthropic had published a specification, a few SDKs and example servers. The useful idea was not that MCP had already become a standard. It was that AI systems were starting to need a shared way to reach tools and data without rebuilding the same connector for every model.
One year later, that bet looks less speculative.
On December 9, Anthropic donated MCP to the newly formed Agentic AI Foundation under the Linux Foundation. The foundation is being launched with Anthropic, Block and OpenAI, with support from companies including Google, Microsoft, AWS, Cloudflare and Bloomberg. Anthropic says there are now more than 10,000 active public MCP servers and lists adoption across ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code.
That does not mean MCP is finished. It means the problem it addresses has become shared infrastructure.
The last twelve months made the difference in lifecycle obvious.
Model names change quickly. A model can be the default choice in January and feel old by summer. Reasoning modes change. Context limits change. Pricing changes. Entire model families can be replaced while the product around them remains.
Integrations move more slowly.
A production system still needs access to repositories, databases, internal services, file stores and business tools. Authentication has to work. Permissions have to be enforced. Data formats have to be understood. The connection needs logs, retries and predictable failure behaviour.
If every new model requires every external system to implement another proprietary integration, the architecture does not scale.
That is the part MCP tries to separate.
The model can change. The client can change. The system exposing the tool or data can keep speaking the same protocol.
A protocol is useful only when unrelated parties choose to implement it.
That is why the important MCP story in 2025 is not a new field in the specification. It is the movement across vendor boundaries.
OpenAI added support for remote MCP servers to the Responses API in May. Microsoft announced broad first-party MCP support across GitHub, Copilot Studio, Dynamics 365, Azure AI Foundry, Semantic Kernel and Windows 11 during Build. GitHub moved MCP support in VS Code to general availability in July and extended it across other IDEs.
Then in September, GitHub announced that its GitHub App-based Copilot Extensions would be retired in favour of MCP servers. The reason it gave is the interesting part: Copilot Extensions were specific to Copilot, while an MCP server can be used by any compatible agent or chatbot.
That is what interoperability looks like in practice.
The value is not that every vendor uses identical internal architecture. They do not need to. The value is that the boundary between the AI system and the external capability can remain portable.
For founders, this changes an important risk calculation.
Choosing a model is becoming a reversible decision. Choosing an integration architecture can be much harder to reverse.
If I build ten internal tools around one vendor's proprietary function format, switching the model may require rewriting the connection layer. If those tools expose a common protocol, the model becomes easier to replace.
That does not make model choice irrelevant. Different models still vary in tool selection, reasoning, latency and reliability. But the cost of testing another model drops when the rest of the system does not need to be rebuilt around it.
I think that is one reason standards become more valuable as models improve faster.
Fast model turnover creates pressure for slower layers to stabilise.
I would not turn this into a claim that MCP solves agent architecture.
It does not manage long-running tasks by itself. It does not decide how memory should work. It does not verify that an agent completed a job correctly. It does not remove the need for authentication, permissions or application-specific validation.
A protocol can standardise how capabilities are described and invoked. It cannot decide whether those capabilities are safe to expose or whether the result is correct.
The same applies to the other projects joining the Agentic AI Foundation.
Block is contributing goose, an agent framework. OpenAI is contributing AGENTS.md, a convention for giving coding agents repository-specific instructions. These solve different problems from MCP. The Linux Foundation is putting all three under the same neutral foundation rather than collapsing them into one framework.
That is healthy.
An ecosystem becomes easier to build when separate layers have separate contracts instead of one framework trying to own everything.
There is a pattern here that software has seen before.
HTTP did not determine how every web application worked internally. SQL did not make every database identical. Language Server Protocol did not make every editor or programming language use the same implementation.
The point of the shared layer was narrower: agree on enough of the boundary that independent systems can work together.
AI infrastructure is reaching the stage where that matters.
Models are no longer isolated endpoints generating text. They are clients of tools, data sources and software environments. Agents are becoming hosts for multiple capabilities. Once that happens, proprietary one-off adapters become architectural friction.
The Linux Foundation is a sensible home for this kind of work because neutral governance can make it easier for competing vendors to invest in the same interface without one company owning the protocol. Anthropic describes vendor neutrality and community governance as explicit reasons for the donation.
The donation does not guarantee success. Standards can fragment. Extensions can become incompatible. Security requirements can force different implementations. A specification can survive while the ecosystem moves somewhere else.
But neutral ownership removes one obvious reason not to adopt it.
The value is easy to see in the kind of systems I work with.
A production pipeline may include an asset database, Blender tooling, render management, source control, build infrastructure, documentation and internal automation.
I do not want the Blender integration rewritten because we changed the reasoning model.
I do not want the asset database to understand whether the client is Claude, ChatGPT, Gemini or an internal agent.
I want the pipeline to expose a controlled capability such as validate_asset, get_render_status or find_project_rule, with authentication and project logic owned by the system that already knows those rules.
Then the AI layer can change independently.
This is similar to how I think about 3D file formats and pipeline contracts. A useful interchange layer should preserve the information different applications agree to share without forcing them to become the same application.
The more AI gets embedded across production tools, the more valuable that separation becomes.
When I wrote about MCP in November 2024, the main argument was that model intelligence and context access were different layers.
I still think that distinction holds.
Models have improved quickly since then. The connection problem did not disappear. If anything, more capable agents made it more visible because they can use more systems and therefore need more integrations.
MCP's 2025 adoption suggests that the ecosystem is starting to treat those integrations as reusable infrastructure rather than features tied to one assistant. OpenAI, Microsoft and GitHub adopting the protocol independently is more meaningful to me than Anthropic adding another MCP feature itself.
The Agentic AI Foundation is an early sign that agent infrastructure may develop its own neutral standards layer.
I would still avoid assuming MCP itself is permanent. Another protocol could replace it. The specification will change. Some companies will keep proprietary interfaces where they have good reasons to.
The broader prediction is the part I have more confidence in now: models will change faster than the infrastructure connecting them to the rest of software.
That makes open boundaries valuable.
A model generation may define what an AI system can reason about this year.
A good protocol can define how several generations of models interact with the same world.
More