Anthropic's Model Context Protocol (MCP) is becoming a common way to wire AI agents into tools and data, now under a newly formed Linux Foundation governance body.
The enterprise AI conversation is moving from which model to buy to a quieter, more operational question: who decides which tools your AI agent is allowed to call. That governance gap is now the most concrete thing the Model Context Protocol (MCP), a vendor-neutral coordination layer for AI agents, brings into the average enterprise platform team's lap.
MCP works as a thin layer above the model. Instead of every application hand-wiring its AI assistant to every external service or database, MCP gives agents a standard way to discover tools, pull in memory, and reach into business systems. As EE Times reports, MCP functions as "a coordination layer above the model, supporting memory access, tool discovery, and interaction with external services and data sources." For an enterprise architect, the practical question is no longer whether to expose a system to an agent. It is which MCP servers the agent is allowed to see, and who approved them.
The protocol's design is what makes that question unavoidable. MCP is not controlled through a central repository, and anyone can write an MCP server. There is no formal, foundation-maintained list of approved tools; the Linux Foundation "recommends certain registries but does not maintain a formal list of approved tools," according to the same EE Times reporting. The Linux Foundation's newly announced governance home for the protocol, the Agentic AI Foundation (AAIF), confirmed in its own press release and seeded by Anthropic's donation of MCP, positions itself explicitly as a vendor-neutral steward, not a gatekeeper.
That is the tension running through every production conversation about MCP. Evangelists frame the open, anyone-can-build model as the feature: a wider pool of integrations, faster adoption, no single vendor in the approval loop. Enterprise security teams see the same property as a supply-chain gap. The strongest public adoption signal in the reference set is Ram Iyengar, chief evangelist at the Cloud Foundry Foundation, telling EE Times at the MCP Dev Summit Mumbai that "MCP has changed how LLMs discover tools and capabilities and has become widely adopted across AI agent ecosystems." That is one expert asserting ubiquity, not a measured market claim.
What the protocol actually hands to enterprise teams is a four-part governance toolkit: registries that catalog available MCP servers, gateways that route and inspect calls, and allowlists and blocklists that determine which tools any given agent can reach. Each of those choices used to be a vendor's problem. Under MCP, they are now the platform team's. As Iyengar put it in the EE Times interview, these four primitives are how an enterprise keeps control over what its agents can do, preserving "security, reliability, and cost control" while letting the agent reach broadly. None of those primitives, however, ships preconfigured with an approved-tools list. The Linux Foundation will recommend registries; it will not hand an enterprise a default-deny policy.
The Agentic AI Foundation is too new to fill that gap. Anthropic's announcement frames AAIF as a vendor-neutral governance home, and the Linux Foundation's own release repeats that language. Vendor-neutral governance is a direction, not a deliverable. There is no public roadmap yet for AAIF-issued registries, signing requirements, or approved-server lists, and the foundation has not signaled that such a list is coming. Until it does, every enterprise rolling out MCP is rolling out its own policy from scratch, with whatever defaults its security team is comfortable inheriting from a community-driven server ecosystem.
For a platform engineering or enterprise architecture reader, the practical watch list is short. Treat the "widely adopted" framing as one expert's read, not a measured market claim; the reference set has no independent adoption count. Expect AAIF to behave as a forum and standards host before it behaves as a gatekeeper, useful for shared schemas and slow for any short, sanctioned tool list. The question worth raising in your next architecture review is not whether to adopt MCP but who, inside your organization, owns the MCP registry choice, the gateway policy, and the allowlist review, because right now the protocol does not.