Hello, this is Hamamoto from TIMEWELL. Over the past year or so, whenever I have talked with executives about using AI inside their companies, the term "MCP" has come up almost without fail. Some technically minded people ask me, "Should we make sure we support MCP too?" Others have only heard the name and are unsure what it actually is.
What I find striking is that these three letters have been in the world for less than two years. Anthropic introduced the Model Context Protocol in November 2024[^1]. And yet it has already been adopted by OpenAI, Google, and Microsoft, and placed under the umbrella of the Linux Foundation as the "industry standard." I struggle to recall a recent example in the IT industry of a standard settling into place this quickly. In this article, I want to trace only the primary sources from Anthropic and the official documentation to lay out why MCP claimed the enterprise-standard seat in such a short period, what the roadmap toward 2026 is aiming for, and what management and DX leaders should decide before adopting it internally.
The past year and a half: how MCP became the standard
Let me start from the beginning. On November 25, 2024, Anthropic introduced MCP, positioning it as "a new open standard for connecting AI assistants to the systems where data lives"[^1]. By systems, they meant content repositories, business tools, and development environments. The company published the specification and SDKs, made Claude Desktop able to connect to local servers, and also released open-source pre-built servers for major tools such as Google Drive, Slack, GitHub, Git, and Postgres. Block and Apollo were named among the early adopters, and on the developer-tools side, Zed, Replit, Codeium, and Sourcegraph were said to be advancing their support[^1].
Here I want to put into words what MCP set out to solve. Historically, letting AI touch your in-house data and tools meant writing bespoke integrations for each model and each tool. The more combinations you had, the more the number of connections multiplied. If you have three models and five tools, you are looking at fifteen integrations to build and maintain, and every new model or tool you add makes the grid grow again. In practice, this is where a great many internal AI projects quietly stall: the proof of concept works, but wiring it into real systems in a way someone can keep running turns into an endless integration backlog. MCP's idea is to run a single common convention through the space "between AI and tools," turning integration from multiplication into addition. Each tool exposes itself once, in the shared MCP way, and every MCP-capable model can then reach it. The aim closely resembles how USB consolidated peripheral connections into a single standard: before USB, every device needed its own port and its own driver; afterward, one shape of connector served them all. I dug into the background of this thinking in an earlier piece, From APIs to MCP and CLIs: connection conventions for the AI agent era, so reading them together should give you a more three-dimensional view.
It is worth pausing on why this mattered so much. A protocol released by a single company, no matter how technically elegant, carries a quiet risk for anyone adopting it: if that company changes its priorities or its business model, the standard can be pulled out from under you. What turns a good idea into a genuine standard is when parties who compete fiercely everywhere else agree to converge on the same convention here, because the shared value of interoperability outweighs the advantage of owning a private interface. That is precisely what happened with MCP, and it happened unusually fast.
What clinched standardization was that vendors other than the originator climbed aboard one after another. On March 26, 2025, OpenAI announced it would adopt MCP. Sam Altman said on X that people love MCP and that he was excited to add support across their products, and revealed that they had added support in the Agents SDK the same day[^2]. A few weeks later, on April 9, 2025, Google announced that it would support MCP in its Gemini models and SDK. DeepMind CEO Demis Hassabis called MCP a good protocol that was rapidly becoming an open standard for the AI agent era[^3]. It is not something that happens often in this industry for competitors to ride the very same standard.
Then, on December 9, 2025, the matter was settled institutionally. The Linux Foundation announced the formation of a new organization, the Agentic AI Foundation (AAIF), placing Anthropic's MCP, Block's goose, and OpenAI's AGENTS.md as anchor projects[^6]. Platinum members included AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. Anthropic donated MCP to this foundation, and the project became an organization under the Linux Foundation, with code provided under Apache License 2.0 and documentation under CC BY 4.0[^7]. As of the donation announcement, there were said to be more than 10,000 public, active MCP servers, and the Python and TypeScript SDKs were reportedly downloaded more than 97 million times per month[^7]. When Anthropic Chief Product Officer Mike Krieger said MCP had "in one year become the industry standard for connecting AI systems to data and tools"[^6], I take it not as hyperbole but as a description backed by measured figures.
Looking for AI training and consulting?
Learn about WARP training programs and consulting services in our materials.
The four pillars of the 2026 roadmap
Once it became the standard, where does MCP go next? Here the official side draws a clear map. The 2026 MCP Roadmap, published on March 9, 2026, was authored by lead maintainer David Soria Parra and set out four pillars[^9]. These four are, in themselves, the priorities for moving MCP from the stage of "it works" to the stage of "it can be operated at scale, in the enterprise, and safely."
The first is Transport Evolution and Scalability, that is, scaling out the communication foundation. The direction shown is to make HTTP streaming horizontally scalable in a stateless way, and to enable server discovery through the .well-known mechanism[^9]. The second is Agent Communication, refining the Tasks primitive, which handles asynchronous work, with concepts such as retries and deadlines. Tasks itself was introduced as an experimental feature in the November 2025 revision of the specification. It is a framework for durable asynchronous requests, with states such as working, input_required, completed, failed, and cancelled[^4]. I understand it as a foundation laid for an era in which we hand AI agents jobs that take anywhere from a few minutes to several hours.
The third pillar, Governance Maturation, is operational maturity: codifying the contributor ladder and delegating authority to working groups. This is less glamorous than the technical work, but for a standard that competitors now depend on together, a clear, predictable process for how decisions get made is what keeps any single party from quietly steering the protocol in its own direction. And the fourth is Enterprise Readiness, the very theme of this article, covering enterprise-adoption requirements such as audit trails, SSO authentication, gateway behavior, and configuration portability[^9]. Read as a sequence, the four pillars tell a coherent story: first make the transport scale, then let agents handle longer-running work, then mature the way the project is governed, and finally close the gap that keeps regulated enterprises from deploying with confidence.
It is also worth noting that this map is beginning to land in the actual specification. The specification whose release candidate was finalized on May 21, 2026, and whose formal release is planned for July 28, 2026, greatly advances statelessness. It removes the initialize and initialized handshake and the Mcp-Session-Id header, changing the design so that any MCP request may reach any server instance. In addition, headers such as Mcp-Method and Mcp-Name allow load balancers and gateways to route without peeking at the body[^10]. It is also a milestone in this revision that Tasks, which had been an experimental core feature, is promoted to a formal extension[^10]. It may sound mundane, but not having to interpret the body behind load balancing turns out to matter quite a lot in large-scale operations, where every request that a gateway can route cheaply is one less bottleneck as traffic grows.
Enterprise readiness: the reality of SSO, audit logs, and the registry
When you set out to use MCP in earnest in an enterprise, the first thing you run into is not features but governance. Who touched which data, through which AI agent, under what authority? A mechanism that cannot explain this will not pass an IT department's review. In my experience, this is the exact point where promising pilots die: a small team demonstrates something genuinely useful, and then the request to roll it out company-wide meets a wall of questions about access control and traceability that the prototype was never built to answer. Getting the governance model right early is not bureaucratic overhead; it is what determines whether the useful thing ever leaves the sandbox.
MCP has been steadily firming up this area over the course of a year. The November 25, 2025 revision of the specification overhauled the authorization framework: it added support for OpenID Connect Discovery 1.0, incremental scope consent using the WWW-Authenticate header, and an OAuth Client ID Metadata Documents approach in place of Dynamic Client Registration[^5]. Alongside this, it set the default dialect for schema definitions to JSON Schema 2020-12[^5]. In short, the specification-level foundation is now in place to integrate cleanly with an in-house identity provider and to grant only the necessary permissions incrementally. It is a form in which MCP has met enterprises halfway, aligning with the governance conventions companies routinely practice: authenticate employees via SSO, then run agents with permissions tied to that identity.
Here is one caveat on how to read the roadmap. The 2026 roadmap intentionally leaves the details of Enterprise Readiness undecided in the core specification, and states explicitly that the expected deliverables are likely to be implemented not as changes to the core spec but as extensions[^9]. I consider this a sound judgment. The format of audit logs and the behavior of gateways differ from company to company. Forcing them into the core specification would only make the standard heavier. Keep the core light, and absorb enterprise requirements through extensions. As a design philosophy for a standard meant to be used for a long time, this is entirely reasonable.
Let me also touch on the registry. I noted that MCP servers have exceeded 10,000, but the mechanisms for finding and choosing among them are growing too. As of the November 2025 release, the MCP Registry had grown 407% since its September announcement to reach roughly 2,000 entries, with 58 maintainers supporting the core team, more than 2,900 contributors on Discord, and over 100 new contributors joining each week[^4]. The scale of the ecosystem is a factor you cannot ignore when choosing a standard, because a standard is only as useful as the servers and clients that actually speak it, and momentum on this order tends to be self-reinforcing. I have compiled the essentials for building a server in-house in the MCP server self-build guide, but the realistic order is to first look for something usable in the public registry and build only the parts that are missing.
One more point on governance: the neutrality of the operating structure is a reassurance for enterprises. Even after the move to AAIF, MCP's technical governance remains unchanged, retaining the maintainer hierarchy of Lead, Core, Maintainers, and Contributors, along with the SEP (proposal) process. The Linux Foundation is said not to dictate MCP's technical direction, and the design leaves day-to-day decision-making to the existing maintainers[^8]. Being a standard whose fate is not held by a single company works in your favor when you have to explain internally "why we are choosing this."
What management and DX leaders should decide now
Given all of the above, then, what should your own company decide? Let me step back one pace from the technology and talk about decision-making.
In my assessment, the decision that management and DX leaders should make right now is not "whether to adopt MCP." That became, in effect, a given the moment major AI products adopted it in unison. The tools your employees already touch, such as ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code, can speak MCP[^8]. If so, the point of discussion lies on the operational-design side: in what order, and under what governance, will you connect your in-house data and tools to MCP?
The things you actually need to decide are not many. First, how to handle authentication. Firm up, in advance, a policy of integrating with SSO and tying permissions to employee identity. The specification side laid the groundwork in the November 2025 revision, with OpenID Connect support and more[^5], so what remains is the design decision of how to connect it to your own identity provider. Second, how to hold audit logs. Record which agent touched which data, in a form you can trace afterward. This too is placed as a pillar of enterprise requirements in the roadmap[^9], and since the flow is to implement it as extensions, articulating in advance what you will make mandatory requirements keeps the adoption from wobbling. Third, drawing the line between which servers you trust and use and which you build in-house. Among the more than 10,000 public servers[^7], there is naturally a mix of gems and junk. I recommend preparing a light review process, however small, for selecting what may be used company-wide.
Notice that none of these three decisions are really about the protocol's internals. They are about your own posture toward it: which identity system is the source of truth, what you insist on being able to audit, and how much of the public ecosystem you are willing to trust. These are governance questions that would exist in some form no matter which technical standard won. MCP simply gives you a stable target to attach them to, which is exactly why it is worth making them now rather than deferring them until a project is already in production and the answers become expensive to change.
Conversely, there are things you do not need to rush to decide right now. The specification is still moving. Just as the handshake is removed and statelessness advances in the July 28, 2026 revision[^10], the foundational conventions are mid-evolution. If you rush into heavy, bespoke construction of your own here, you will be left behind by the evolution of the standard. Ride the standard straight for the core connections, and add company-specific requirements through extensions. I think it is wise for the adopting side to borrow, as is, the design philosophy MCP itself chose. Rather than rushing to build everything, keep a thin construction that can follow the standard's changes. Simply holding onto this one point at the management level will make your debt years from now considerably lighter.
AI agent operational design, with WARP alongside you
That said, having read this far, I suspect many of you feel, "I understand the policy, but where do we actually start?" There is a practical distance between the standard being settled and being able to run it in your own company. Closing that distance together is the role of our AI consulting service, WARP.
At WARP, we place importance on bringing the operational design of MCP-premised AI agents down not to a picture-perfect concept but to a form the front line can actually run. For example, prioritizing which in-house data source to begin the connection from. How to build in SSO and audit logs, and how to design governance that can withstand an IT department's review. How far to use servers from the public registry, and from what point to switch to in-house builds. Judgments like these are not decided by technology alone or by management alone. They require a perspective that connects both, because a choice that looks efficient to engineers can be unacceptable to a security review, and a policy that satisfies governance can be so heavy that no team actually adopts it. The work is to find the design that both sides can live with. For those who want to raise the resolution of implementation another notch, the Claude Agent SDK implementation guide, which goes into the specifics of development, should be helpful.
The fact that MCP has become the industry standard also means, conversely, that the excuse of "wait and see" no longer works. Given that the tools your employees use speak MCP across the board, if you leave the governance of connections undesigned, a state can quietly arise in which you no longer know who is touching which data. Riding the standard does not mean it is fine to leave it alone. Rather, the work of designing how you ride it starts from here. If you would like to discuss where to begin assembling your own AI agent operations, on both the governance and implementation fronts, please reach out via Book a consultation. Precisely because the standard has now settled, I believe it is worth spending time on design.
References
[^1]: Introducing the Model Context Protocol — Anthropic — November 25, 2024 [^2]: OpenAI adopts rival Anthropic's standard for connecting AI models to data — TechCrunch — March 26, 2025 [^3]: Google says it'll embrace Anthropic's standard for connecting AI models to data — TechCrunch — April 9, 2025 [^4]: One Year of MCP: November 2025 Spec Release — Model Context Protocol (official blog) — November 25, 2025 [^5]: Key Changes — Specification 2025-11-25 Changelog — Model Context Protocol — November 25, 2025 [^6]: Linux Foundation Announces the Formation of the Agentic AI Foundation (AAIF) — Linux Foundation — December 9, 2025 [^7]: Donating the Model Context Protocol and establishing the Agentic AI Foundation — Anthropic — December 9, 2025 [^8]: MCP joins the Agentic AI Foundation — Model Context Protocol (official blog) — December 9, 2025 [^9]: The 2026 MCP Roadmap — Model Context Protocol (official blog) — March 9, 2026 [^10]: The 2026-07-28 MCP Specification Release Candidate — Model Context Protocol (official blog) — May 21, 2026