the plug, not the intelligence

MCP is not smarter AI. The Model Context Protocol is a plug standard: an agreement on how an AI program can read and act in the software you already have, from accounting to planning. In thirteen months that agreement grew from an Anthropic project into an industry standard under the Linux Foundation, embraced by OpenAI, Google and Microsoft. That explains why vendors suddenly stamp “agent-ready” on everything. But adoption of the standard says nothing about the two questions that matter to you: is your software connected to it yet, and can the connection that does exist be trusted? On both, the honest answer for now: usually not, unless you check.

In context beats the prompt I wrote that an AI is only as good as the information it can reach. This essay is about the layer beneath that: the door it comes in through.

what exactly is mcp?

Plumbing, and I mean that as a compliment. Before MCP, every combination of AI application and software package needed its own custom integration: ten programs on ten systems is a hundred integrations. With MCP, each system builds one interface, an MCP server, and every AI application that speaks the standard can connect to it: ten plus ten instead of ten times ten. Through such a server a language model can call tools, actions in other words, and read data, always along the same pattern.

Anthropic introduced the protocol on 25 November 2024 as an open standard, with ready-made servers for GitHub, Slack and Postgres among others (Anthropic, 2024). A good year later, on 9 December 2025, the company handed governance over to the Agentic AI Foundation under the Linux Foundation, co-founded with Block and OpenAI and backed by Google, Microsoft, AWS and others (Anthropic and Linux Foundation, 2025). At that handover Anthropic itself reported over ten thousand active public MCP servers and more than 97 million SDK downloads per month. Those are numbers from the steward of the standard, so read them as self-reporting, but the order of magnitude fits what was visibly happening.

why are you suddenly hearing about it everywhere?

Because the inventor’s competitors embraced it, and fast. On 26 March 2025 OpenAI announced MCP support through Sam Altman and joined the steering committee (TechCrunch, 2025). Two weeks later Google DeepMind followed, with Demis Hassabis publicly calling MCP “a good protocol that is rapidly becoming an open standard for the agentic era” (TechCrunch, 2025). Microsoft built it into Copilot Studio and even into Windows 11 (Microsoft, 2025). Four parties that compete on every other front picked the same plug within five months. That rarely happens, and it is the real news: not that AI got smarter, but that for the first time there is one door everyone wants to walk through.

For a business, that door means something concrete. Software whose actions are reachable through such an interface can be operated by people and by agents, with the same actions. That is the difference I describe from the building side in why I built an agent-native crm. But mind the word can: the standard makes it possible, not a given.

is your software ready for it?

Probably not at first hand, and that is one of the most sobering findings from the research for this essay. None of the major Dutch SMB software vendors offered an official MCP server of their own at the time of writing. What does exist: third-party wrappers, such as a unified API vendor laying exactly the same MCP shell over twelve different accounting packages (Apideck, 2026). That can be legitimate and useful. But it fundamentally changes the trust question: not “do I trust my accounting package” but “do I trust the intermediary allowed into my books on my agent’s behalf”.

Add to that the standard’s youth. Thirteen months brought three sizable revisions, including a fundamental tightening of authorization in mid-2025 and a major update exactly one year after launch (WorkOS, 2025). That is normal for a young standard, HTTPS and OAuth also matured step by step, but it does mean that the “MCP support” claimed today can carry different guarantees next year. So do not ask whether a vendor supports MCP, ask which version, and who maintains the connection.

how secure is it?

The standard does not enforce security, and the measurements show what that means. A study of nearly eight thousand live remote MCP servers found that 40.55 percent enforce no authentication at all (arXiv, 2026). A peer-reviewed measurement of 1,899 open-source servers found a serious vulnerability in 7.2 percent, with leaked credentials the most common, and susceptibility to tool poisoning in 5.5 percent (arXiv, 2025). What is interesting is where the risk sits: the official reference servers scored zero found vulnerabilities in that research, the long tail of community servers a median of two each. The problem is not the standard, it is the sprawl around it.

Tool poisoning deserves an explanation in plain language, because it is the most concrete new risk. Every tool an agent can use carries a description the human never gets to see, but the language model does read. Security researchers showed in April 2025 that you can hide instructions in that description which the model dutifully follows (Invariant Labs, 2025). In a benchmark with deliberately poisoned tools, even the best performing model fell for it in over two thirds of the attacks, and more capable models turned out to be more susceptible, because the attack abuses their strong instruction-following behavior (MCPTox, 2025). That is a laboratory number under targeted attack conditions, not measured real-world damage, but the direction is clear. Simon Willison sums it up as the lethal trifecta: an agent with access to private data, exposure to untrusted content and a channel to the outside world is a risk, and connection standards make it easier to switch those three on at the same time by accident (Willison, 2025). The Dutch Data Protection Authority warned in February 2026 about precisely this risk pattern in autonomous AI agents with plug-ins, without naming MCP (AP, 2026). How you cover those risks in practice, permissions, scopes and logging instead of good intentions, is in the guardrails.

what do you ask before you let an agent loose on your software?

Six questions, no technical background required.

1. Is the MCP server from the vendor itself, or from a third party? And who maintains it at the next spec version?
2. Exactly which rights does the agent get: read, write, which parts? All-or-nothing is a red flag.
3. Does the connection run with authentication, and where do the keys live? Over forty percent of live servers enforce nothing; ask explicitly how yours does.
4. Who reviews the tools and the descriptions the model gets to read, and when did that last happen?
5. What is logged of what the agent does, and can you inspect it yourself?
6. What happens on a mistake: is the action reversible, and when is a human brought in?

The plug standard is here, and it is serious: carried by the whole industry, governed by a neutral foundation, and capable of making software genuinely operable by agents. What the standard does not deliver is the judgment about who gets to plug into your systems. That remains an architecture and governance question, and nobody answers it for you.