MCP: How AI Connects to Your Tools

What it is, in one sentence

MCP — Model Context Protocol — exists so that the AI does not need a separate integration written for every tool. It is a standard protocol: the server describes what tools it has, and the client (the agent) asks in the same language no matter which server it is talking to.

The practical benefit follows from there: if you have an MCP server for your own system, then any agent that speaks the protocol can connect to it — you do not have to build separately for each one.

What changed since 2025: it is no longer one company's protocol

This is the most important update, because plenty of sources still describe it as "the protocol of a model developer company".

According to the official governance document, MCP today is a project operating under the umbrella of the Linux Foundation. The code and the specification are covered by the Apache 2.0 licence, the documentation by Creative Commons.

And there is one principle worth knowing word for word: in the technical governance, membership attaches to individuals, not to companies — there are no seats reserved for particular firms.

This is not a formality. It means that the standard you build your integrations on does not depend on the business decision of a single company.

The 2026 specification is not a tune-up

The version numbering is itself informative: MCP uses date-based versions, and the number marks the day on which the last backwards-incompatible change was made. The current one is 2026-07-28. The sequence so far: 2024-11-05 → 2025-03-26 → 2025-06-18 → 2025-11-25 → 2026-07-28.

The last step rewrote the architecture:

• Protocol-level sessions are gone. The session identifier header has been deleted. If a server needs to keep state between calls, it does so with an explicit identifier issued by the server, which travels as an ordinary tool argument.
• MCP became stateless. The opening handshake was deleted too — every request carries the protocol version and the client's capabilities with it.
• A new mandatory call through which the server states which versions and capabilities it supports.
• Three earlier features became deprecated, and the old HTTP-based transport was formally deprecated as well.

The practical message: if a write-up talks about an opening handshake or a session identifier, it is out of date. That has been the case since the summer of 2026.

One piece of good news arrived at the same time: a deprecation policy was introduced. A feature's status can be active / deprecated / removed, the deprecation window is at least twelve months (even in the expedited case a minimum of ninety days), and there is a public register of retired features. For a protocol, that is a sign of growing up.

How big is the ecosystem?

There is an official registry, and it can be queried. So I did — I paged through the entire register on 12 September 2026:

(Own measurement against the official registry API, paging through 1,017 pages.)

So: more than thirty thousand unique servers in a single year — with three published versions each on average. New entries were still arriving on the day I queried it.

Two limitations worth knowing. The registry is in a preview state — its maintainers themselves write that breaking changes or data restores may happen. And it does not contain private or internal servers, so the real number is higher than this.

The third limitation is the most important one, and it is about security: the registry explicitly says of itself that it delegates security review to the package registries and to the downstream marketplaces. It handles namespace verification and metadata.

Getting into the official registry is therefore not a security certificate.

The security side

This section is the reason MCP cannot simply be "wired up".

Own measurement, on the same day, in the national vulnerability database:

More than doubled in a year, and roughly 70% of the hits are rated high or critical.

Four patterns stand out among them, and all four are instructive.

The first: the reference implementations are no exception either. One of the protocol authors' own servers allowed zero-click data exfiltration (critical, score 9.3, July 2025): the agent generated a message in which an attacker-injected reference carried the data out unseen, and the bot generating the link preview fetched it on its own. On the same day, two other official servers turned out to allow escaping the permitted directories.

The second: the official developer tools too. The protocol's own debugger got a critical remote code execution flaw scored 9.4, because there was no authentication between the client and the proxy.

The third, and this is the most telling: all five official SDKs fell into the same trap. The Python, TypeScript, Go, Java and Rust versions all produced the same bug — by default there was no protection against a particular, long-known network attack, so a malicious web page could reach the MCP server running on your own machine. This is not a story about one sloppy developer, it is a story about a flaw that arose around the protocol, not underneath it.

The fourth: permission checks in the wrong layer. One server documented three environment variables as access control — but they only took effect at tool listing, not on the actual call. Anyone who knew a tool's name could invoke it directly. Filtering the list is not permission management — there is no cleaner textbook example than this.

And there is an attack with no vulnerability number, because it is not an implementation bug: tool poisoning. A malicious server supplies a tool description that talks the agent itself into doing something. In the published demo the agent leaked its own configuration file and the SSH keys. In the craftier variant, the description overrides the behaviour of another, trusted tool — in the published example, an instruction hidden in the description of a harmless addition tool told the mail-sending tool to send every message to the attacker's address from now on, and not to mention this to the user.

What the specification itself says

It is worth reading, because it is unusually honest.

The opening sentence of the security chapter: the protocol enables arbitrary data access and code execution paths, and that power comes with important trust considerations.

The requirements, in mandatory form:

• the user must explicitly consent to every data access and operation, and must understand them;
• the host must obtain explicit consent before passing user data to a server;
• explicit consent is required before invoking a tool;
• and the most important sentence: the text describing tool behaviour must be treated as untrusted unless it came from a trusted server.

That last point is exactly about tool poisoning — the specification itself warns about it.

But the most candid sentence is this one: the protocol cannot enforce these principles at the protocol level. The responsibility lies with the client.

On top of that, the official security guide describes ten named attacks with diagrams — from the confused deputy through token passthrough and internal network access to the compromise of a local server. This is not a theoretical risk list: the protocol's own documentation enumerates ten concrete ways it can go wrong.

A2A: not a competitor

A common question is whether MCP has a rival. The short answer: not a rival but a complement — and both sides describe it that way.

And an interesting observation: A2A was built by a large technology company, which then donated it to the Linux Foundation as well, with a steering body made up of representatives from eight organisations, again under Apache 2.0.

So by 2026 both main standards of agent interoperability have left the hands of their founding company for a neutral foundation. That is news in itself.

Common misconceptions

• "MCP is one company's protocol." Not any more. It is under the Linux Foundation, with an Apache 2.0 licence, and governance has no company-assigned seats.
• "If it is in the official registry, it is safe." The registry itself states that it leaves security review to others. It gives namespace verification, not a certificate.
• "The official servers are safe." Among the reference implementations there was a critical, zero-click data leak, and all five official SDKs produced the same bug.
• "The tool description is only documentation." According to the specification it is untrusted input, from which a working attack can be built.
• "The protocol enforces approval." It cannot. It makes it mandatory, but enforcement is down to the client.
• "I filtered it out of the list, so it cannot be reached." No. In at least one documented case the filtering applied to listing only, not to the call.

What to take away

MCP is a good thing: a standard that removes the quadratic growth of integrations, now tended by a neutral foundation, with a deprecation policy and standardised observability. A grown-up protocol.

But two things are worth keeping in mind. One: wiring something up is not an installation, it is a trust decision — the tool description is input, not documentation, and the protocol cannot make that call for you. Two: permissions have to be checked at the call, not at the listing — and that mistake was made not by an amateur but by several live servers.

Exactly how the tool call works from the model's side is spelled out in the tool use and function calling post, field by field; and for narrowing permissions down, the least-privilege agent post hands you a practical recipe.