TL;DR. MCP is no longer a bet. Since December 2025, the Model Context Protocol has been with the Agentic AI Foundation under the Linux Foundation, backed by Anthropic, OpenAI, Block, Google, Microsoft, AWS, Cloudflare and Bloomberg. The new specification came out on July 28, 2026: MCP is now stateless and, for the first time, can run cleanly behind ordinary load balancers. Security, however, does not come with the protocol. In April, Trend Micro counted 1,467 publicly reachable MCP servers without authentication, almost three times as many as in its first scan. If you connect, you have to secure it yourself. The checklist is below.
From experiment to foundation: what happened in December
When Anthropic published the Model Context Protocol at the end of 2024, it was a proposal: an open standard through which AI assistants talk to tools and data sources, instead of building a separate integration for every combination of model and system. Whether the proposal would catch on was for a long time the real question for anyone asked to invest budget.
That question has been answered. On December 9, 2025, Anthropic handed the protocol to the Agentic AI Foundation, a directed fund of the Linux Foundation. It was founded with three projects: MCP from Anthropic, AGENTS.md from OpenAI and the goose agent framework from Block. Platinum members include these three plus AWS, Bloomberg, Cloudflare, Google and Microsoft.
For decision-makers this is the relevant point. A standard owned by a single vendor is a risk. A standard under a neutral foundation with a formal deprecation policy is infrastructure you can plan on. At the time of the handover there were more than 10,000 active public MCP servers and over 97 million SDK downloads a month. MCP ran in ChatGPT, Claude, Gemini, Microsoft Copilot, Cursor and VS Code. By July 2026, the project reported close to half a billion monthly downloads for its main SDKs.
One server, every client: why it pays off
The business logic of MCP is unspectacular and convincing for exactly that reason. Before MCP, “making our data usable for AI” meant a separate integration for every assistant, each with its own maintenance, its own sign-in concept and its own risk of breaking with updates. With MCP you build the integration once, as an MCP server in front of your ERP, your knowledge base or your ticket system. Every MCP-capable client can use it.
We see that this pattern holds in our own work. We build MCP servers as a tool layer for business applications, following the principle of “one back end, two doors”: an interface for people, an MCP access for agents. Same tools, same data contracts, no duplicate maintenance. The effort goes once into clean tool design, not into the umpteenth connection to yet another client.
The big players have long been running this in production. Stripe, PayPal, Shopify, Figma, Notion, Linear, Atlassian, Zapier, MongoDB and Microsoft operate their own MCP servers. With MCP Apps there is now an official extension through which tools return not just text but small interactive interfaces in the chat. The MCP server thus turns from a data supplier into a mini application of its own on the customer’s side.
The July 28 specification: stateless means operable
The next version of the specification was published on July 28, 2026. The most important change sounds technical but is a signal to every IT department: MCP is now stateless.
Until now, every MCP connection needed a start-up handshake and a session ID. The server had to remember who it was talking to. For a developer tool on a laptop that does not matter. For operation behind a load balancer it was a problem, because requests from the same session always had to reach the same server. The new specification removes the handshake and the session ID. Any request can land on any instance. That is scaling like any ordinary web API.
Further changes point in the same direction:
| Change | What it means |
|---|---|
| Stateless operation | Ordinary load balancers instead of sticky sessions |
| Required headers Mcp-Method and Mcp-Name | Gateways, rate limiters and firewalls can route and meter without reading the body |
| Follow-up questions without an open channel | If the server needs input, it says so in its response and the client asks again |
| Stricter sign-in | Issuer validation under RFC 9207, credentials bound to the issuer |
| Extensions framework | Tasks, MCP Apps and enterprise-managed sign-in as clean extensions |
| Deprecation policy | At least twelve months’ notice, for example for the old SSE transport |
Headers for rate limiters, stricter sign-in, deprecation deadlines: these are not features for hobbyists. This is the equipment a protocol needs to live in corporate networks.
The flip side: the ecosystem grows faster than its security
This is exactly where enthusiasm needs to pause. Because while the foundation and the specification have matured, the same is not true of the mass of MCP servers out there.
In July 2025, Trend Micro first scanned the internet for publicly reachable MCP servers and found 492 without any authentication. In its update of April 28, 2026, there were 1,467, almost three times as many. 1,227 of them still use the old SSE transport that the new specification deprecates. These are tool layers with access to internal systems, sitting unprotected on the internet.
Publicly reachable MCP servers without authentication
without authenticationof which 1,227 on the old SSE transport
For the same update, Trend Micro analysed more than 19,000 MCP server source codes. 48% of them recommend storing secrets such as API keys unprotected in .env files or as plain text in JSON. The researchers also found three critical flaws rated CVSS 9.8 in unofficial MCP servers for Azure and AWS.
19,000 MCP server source codes
The client side is an attack surface too. In February 2026, Check Point reported two now-fixed flaws in Claude Code (CVE-2025-59536 and CVE-2026-21852). Prepared project files in a code repository could start MCP servers before the user had trusted the project, or redirect requests including the API key to a foreign server. The lesson: even cloning someone else’s repository with an MCP configuration is a security-relevant act.
Tool poisoning, meaning manipulated tool descriptions that slip hidden instructions to the model, is regarded in the industry as a new form of prompt injection. In short: the protocol has grown up. The discipline in handling it has not, everywhere.
Five points before an MCP server enters your operations
From our own practice building and running MCP servers, condensed to what a mid-sized company without its own security team can manage:
- Keep an inventory, prevent shadow IT. Decide who may connect MCP servers and keep a list: which server runs where, with access to which systems? The 1,467 exposed servers were rarely set up with malice. Mostly, nobody simply recorded them.
- No connection without authentication. An MCP server without sign-in does not belong on the network, not even “internal only, just briefly”. The new specification sets hardened OAuth as the standard route. Use it, or at least a separate key per client.
- Check origins instead of installing blindly. Prefer servers from the vendors themselves, such as Stripe, Notion or Atlassian, or from the official registry. For everything else: read the code or have it read. When almost every second source code stores keys insecurely, trust is out of place.
- Treat tool descriptions as an attack surface. When approving a server, check not only the code but also the tool descriptions; that is where tool poisoning starts. Pin reviewed versions and get alerted when tool definitions change after an update.
- Minimise rights, control configurations. Give each server only the access its tools really need, read-only where read-only is enough. Treat MCP configurations in foreign repositories like executable code. Keep clients and servers consistently up to date and move off the old SSE transport.
None of this is rocket science. It is the same hygiene you would apply to any new piece of internet infrastructure. MCP servers just need it more, because by definition they reach deep into your systems. How an agent can sign in without seeing passwords is shown in our post on the agent authenticator.
What this means for your company
The strategic question “Do we bet on MCP or wait?” has settled itself. A foundation under the Linux Foundation, the big model vendors as backers, a specification built for scaled operation since July 28: if you want to open a data source or business system to AI assistants today, MCP is a standard that will stay and that reaches all relevant clients with one integration.
The operational question has become sharper instead: not whether, but how controlled. The numbers from Trend Micro and Check Point show an ecosystem in which the quality of the building blocks varies widely and unsecured servers almost triple within months. Our advice is therefore calm: start with one clearly scoped system, one MCP server, properly authenticated and with minimal rights. Work through the five points above before the first agent accesses it in production. Then MCP is what it can be by now: industry infrastructure, not an open window. If you want to set up your first server properly, we are happy to talk.
