the plug, not the intelligence

Let me set one thing straight first, because this is where most pieces go wrong right out of the gate: MCP doesn’t make AI smarter. The Model Context Protocol is a plug. That’s it. An agreement on how an AI program gets to read and act in the software you’re already running, from your accounting to your planning. And look, for me this isn’t theory. I work with it every day, through one of these connections on the CRM of an installation firm. What gets me most is the pace. Thirteen months, and it went from an Anthropic project to a full industry standard under the Linux Foundation, with OpenAI, Google and Microsoft all on board. So now vendors stamp “agent-ready” on everything. Thing is, all that adoption tells you nothing about the two things that actually matter to you. Is your software even hooked up to it? And that connection, if there is one, can you trust it? Honest answer to both, for now: usually not. Not unless you go check yourself.

In context beats the prompt I already made the case: an AI is only as good as the information it can get to. This one’s about the layer underneath. The door it comes in through.

what exactly is mcp?

Plumbing. And I mean that as a compliment. Look, before MCP every combination of an AI application and a software package needed its own custom integration. Ten programs on ten systems? A hundred integrations. With MCP each system builds one, a single interface, an MCP server, and any AI application that speaks the standard just plugs into it. Ten plus ten instead of ten times ten. Through that server a language model gets to call tools, so, actions, and read data, always along the same pattern. At that installation firm it comes down to something dead simple: my agent sits in the same CRM as the planning. On the same boards.

Anthropic put the protocol online 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, they handed the governance to the Agentic AI Foundation under the Linux Foundation, co-founded with Block and OpenAI and backed by Google, Microsoft, AWS and a few more (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 a month. Numbers from the steward of the standard, so, self-reported, I weigh them a bit lighter. Though the order of magnitude does fit what you could already see happening.

why are you suddenly hearing about it everywhere?

Because the inventor’s own competitors embraced it, and fast. On 26 March 2025 OpenAI announced MCP support through Sam Altman and pulled up a chair at 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). And Microsoft? Built it into Copilot Studio and even into Windows 11 (Microsoft, 2025). Count along. Four parties that won’t give each other the time of day anywhere else, all picking the same plug inside five months. That almost never happens. And for me that’s the real news: for the first time there was one door everyone wants through. The AI itself didn’t get a day smarter.

For a business, that door means something concrete. Software whose actions you can reach through an interface like this, you can have people run it and agents too. Exact same actions either way. From the building side I describe that difference in why I built an agent-native crm. But watch that little word, can. The standard makes it possible. It doesn’t happen on its own.

what will it bring you?

So much for the plug. And there are worries, sure, I’ll get to those. But honestly, the most interesting question isn’t whether it’s safe enough yet, or finished enough. It’s this: what’s it actually going to bring you?

In my experience? MCP’s a genuine gamechanger. It brings agentic AI right up close to the organization, onto the shop floor, precisely because it can hook straight into the systems you really work in. Without those systems an agent just isn’t up to much. It hasn’t got the context or the tools to do real agentic work in the software you run your business on.

I reckon MCP’s going to become a standard for company software, with a nice straight structure underneath it. That’s how we’ve set it up too. In fikst, everything you can configure, you can configure over the MCP as well. We built it that way from the start, deliberately. And the user configures that structure themselves after, and even that runs through the standard admin role, over the MCP.

So you’re moving toward a market where you don’t even need implementation consultants anymore. A functional admin can set up the whole system, their own automation flows along with it, over the MCP. That’s how you slide, slowly, toward a market where those whole implementation costs just aren’t needed anymore.

is your software ready for it?

Probably not at first hand. And that was honestly the most sober outcome of all the digging for this piece: at the time of writing, not one of the big Dutch SMB software vendors offered an official MCP server itself. Not one. The CRM I work on every day does have one, from the vendor itself. And wouldn’t you know it, that’s not a Dutch package. What you do find here is third-party wrappers. A unified-API vendor lays the exact same MCP shell over twelve different accounting packages (Apideck, 2026). Could be legitimate. Could be useful, sure. Only your trust question shifts a fair bit with it: up to now you trusted your accounting package, and from here on you’ve also got to trust the intermediary that gets into your books on your agent’s behalf. Different question entirely.

Then there’s how young the thing still is. Thirteen months, and already three hefty revisions. Including a real tightening of the authorization mid-2025 and a big update exactly a year after launch (WorkOS, 2025). Nothing strange in itself, HTTPS and OAuth grew up step by step too. But it does mean the “MCP support” they promise you today can carry completely different guarantees next year. In my own stack that adds up quick, by the way: besides the CRM there are connections to Make and Moneybird hanging off it, and every link you’ve got to maintain the moment something shifts somewhere. So keep asking. Which version? And who’s still maintaining that connection down the line? “We support MCP”, on its own, that’s worth very little.

how secure is it?

The standard doesn’t enforce security. And what that gets you, well, by now it’s just been measured. I started reading those measurements for a simple reason: my agents run on real business software. A study of nearly eight thousand live remote MCP servers found that 40.55 percent enforce no authentication whatsoever (arXiv, 2026). Over forty percent. Just wide open. A peer-reviewed measurement of 1,899 open-source servers found a serious vulnerability in 7.2 percent, leaked credentials the front-runner, plus susceptibility to tool poisoning in 5.5 percent (arXiv, 2025). And the most telling bit sits right at the bottom of that research: the official reference servers scored zero vulnerabilities found. That long tail of community servers? A median of two apiece. See it? The problem’s rarely in the standard itself. It’s in the sprawl that’s grown up around it.

Tool poisoning, that one’s worth spelling out in plain language, because it’s the most concrete new risk of the bunch. Every tool an agent can use carries a description. You never get to see it. The language model does. And in April 2025 security researchers showed you can hide instructions inside that description, which the model then 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 here’s the kicker: the more capable models turned out more susceptible, because the attack abuses the very thing they’re good at, following instructions closely (MCPTox, 2025). Fair’s fair, those are laboratory numbers under targeted attack conditions, not real-world damage anyone’s measured. Comes with the territory. But the direction’s clear enough. 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. That’s a risk, and connection standards make it that much easier to flip all three on at once by accident (Willison, 2025). The Dutch Data Protection Authority warned in February 2026 about exactly this risk pattern in autonomous AI agents with plug-ins, without ever naming MCP (AP, 2026). And how you actually guard against this in practice, with permissions and scopes and logging instead of good intentions, that’s in the guardrails.

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

Six questions. You need zero technical background for any of them. And a vendor who gets twitchy about them, well, that tells you something too.

Whose MCP server is it, actually? The vendor’s own, or some third party’s? And who maintains it later, when the next spec version drops? Then the rights: what exactly does the agent get to do? Read, write, which parts? All-or-nothing there is a red flag. Is the connection even running with authentication, and where do the keys live? Over forty percent of the live servers enforce nothing, so just ask, out loud, how yours does it. Who checks the tools and the descriptions the model gets to read, and when did that last actually happen? What’s logged of whatever the agent gets up to, and can you get at it yourself? And the one people skip right up until it bites them: if it goes wrong, can you undo the action? And when does a human step back in?

So the plug’s here. And it’s serious, it really is. The whole industry carries it, a neutral foundation runs it now. And that software genuinely becomes agent-operable because of it, I watch that happen every working day. What the standard won’t hand you is the judgment about who gets to poke around in your systems in the first place. That stays an architecture and governance question. And nobody answers that one for you. Not the vendor, not the foundation. You.