MCP standardises exactly one thing: how an AI application discovers and calls the tools, reads the resources, and uses the prompts that a server exposes, through one interface instead of a bespoke integration for every model-and-system pairing. It says nothing about what an agent should be allowed to do with what it discovers, and it does not replace the permission checks, identity model, or audit trail your systems already need. Since Anthropic introduced it in November 2024, MCP has gone from a new idea to the default way agents get wired up to internal systems - which is exactly why its failure modes now deserve the same scrutiny as any other integration layer that moves business data.
On this page
- What MCP actually standardises
- The integration problem it was built to solve
- How the protocol is put together
- Where MCP fits in an agent architecture
- The security failures already showing up in production
- A practical checklist for adopting MCP safely
- When MCP is the wrong tool
- Frequently asked questions
What MCP actually standardises
A host application, such as a chat client or an agent runtime, embeds one or more MCP clients. Each client holds a connection to one MCP server, and that server exposes three kinds of things: tools the model can invoke, resources the client can pull in as read-only context, and prompts the server defines as reusable templates. The protocol standardises how a client discovers what a server offers, how it calls a tool with structured arguments, and how it gets a structured result back.
What it does not standardise is judgment. MCP gives you a common way to write a tool contract down - a name, a description, an input schema, an output shape - and to make it discoverable at runtime. It has no opinion on which operations belong in that contract, who should be allowed to call them, or what happens when a call fails halfway through. Those decisions still sit with whoever builds the server, exactly as they would for a hand-rolled API. A narrow, well-designed tool contract is still the actual security boundary; MCP just gives that boundary a standard shape.
The integration problem it was built to solve
Before a common protocol, connecting an AI application to an external system meant writing a custom integration for that specific pairing. Ten AI applications and a hundred systems could mean close to a thousand bespoke connections, each with its own auth handling, its own schema, its own failure modes. MCP collapses that to one server per system: build it once, and any MCP-compliant client can use it without a new integration per model.
That framing is a large part of why adoption moved quickly. Anthropic introduced MCP in November 2024; OpenAI added support across its products within months; by December 2025, stewardship of the specification had moved to the Linux Foundation's Agentic AI Foundation, giving the standard a vendor-neutral home rather than a single company's roadmap. Google, Microsoft, AWS, and most of the major agent and API gateway vendors now ship MCP support somewhere in their stack. Exactly how much of that support has reached production is genuinely disputed - survey figures for enterprise adoption range from roughly two in five to as many as four in five teams, depending on who ran the survey and how "in production" was defined - but the direction isn't in question, and well over ten thousand public MCP servers already exist across the official registry and GitHub combined.
How the protocol is put together
The architecture is deliberately simple: a host holds one or more clients, each client keeps a one-to-one connection to a server, and a server declares its tools, resources, and prompts over a JSON-RPC-based transport. That simplicity is also why the protocol has been able to move fast without breaking most existing integrations.
The most recent major revision, published July 28, 2026, reworked the protocol around a stateless core, so a server can behave like an ordinary HTTP service - cacheable, routable, and scalable on standard infrastructure - instead of requiring a long-lived session for every client. The same release added two extensions worth knowing about: MCP Apps, which let a server render a small UI surface inside the host rather than returning plain text, and Tasks, which give a server a structured way to represent long-running work, such as an approval step that will not resolve immediately. Authorization was also pulled closer to familiar OAuth 2.1 and OpenID Connect conventions, and a formal deprecation process through Spec Enhancement Proposals means future revisions are meant to extend the protocol rather than force a rewrite of transport and lifecycle code.
Practically, that history matters because the ecosystem is still mid-transition. Older stateful servers and newer stateless ones are both in active use, and a deployment should pin the spec version it targets rather than assume every server and client on the network speaks the same revision.
Where MCP fits in an agent architecture
MCP sits at the integration layer, not the safety layer. It is a good fit for the mechanics CodeDTX already treats as non-negotiable when agents connect to internal systems securely: a small set of named, schema-declared operations instead of a general-purpose credential. What MCP adds is a standard way to declare and discover that contract - it doesn't decide what belongs in it.
Everything else still has to be engineered around the protocol, not assumed from it. Identity still has to travel with each call rather than being inferred, which is the same distinction covered in handling authentication for an agent acting on a user's behalf. Permission checks still belong in the resource server underneath the MCP layer, never in the tool description or the model's own judgment about whether a call seems reasonable - see stopping an agent from reaching data it should not see. And every call an agent makes through an MCP server, permitted or refused, still needs to land in a record that can be reconstructed later, along the lines set out in what an AI agent audit trail actually needs to contain. Under CodeDTX's Propose-Decide-Execute pattern, an MCP tool is a fine way to let an agent gather evidence or draft a proposal; it should not, by itself, be the route through which an unreviewed write reaches a production system.
The security failures already showing up in production
The industry has had less than two years to find MCP's failure modes, and it has already found several, in shipping software rather than in theory.
Tool poisoning exploits an asymmetry: what a person sees in a tool's name and description is often not the whole of what the model receives. A description can carry hidden instructions appended after the visible text, invisible in most interfaces but read by the model as part of its context and followed as though it were authoritative. A public demonstration against the WhatsApp MCP server in April 2025 used exactly this technique to attempt to extract a user's chat history, without needing to bypass authentication or exploit a code vulnerability at all - the model simply did what the poisoned description told it to.
Tool shadowing is a variant of the same idea at the server level: a second, malicious server registers a tool whose name or description is close enough to a legitimate one that it intercepts calls meant for the real thing.
Indirect prompt injection through retrieved content is a distinct failure from tool poisoning, and arguably more common, because it doesn't require compromising a server at all. In May 2025, researchers showed that text planted in public GitHub issues and pull requests could manipulate an agent connected through the GitHub MCP server into leaking private repository code into a public PR - the injected instructions arrived as ordinary content the tool was asked to fetch, not as part of the tool's own description.
These aren't exotic bugs. OWASP has since stood up a dedicated MCP-focused project cataloguing this class of risk - token and secret mismanagement, privilege escalation through scope creep, tool poisoning, and shadow servers among them - and while the project is still maturing, it's already a usable checklist. Underneath the AI-specific framing, the CVE record for MCP implementations looks a lot like the CVE record for any other network service: in the opening months of 2026 alone, researchers filed more than thirty CVEs against MCP servers, and a large share trace back to the oldest bug in the book - a server built as a thin wrapper around a command-line tool, passing model-supplied arguments straight into a shell call without sanitising them first.
A practical checklist for adopting MCP safely
- Review tool descriptions like a permissions change, not a config edit. A diff to a tool's description can change what the model believes it's allowed to do, whether or not it changes what the server actually does.
- Prefer your own internal server or gateway in front of systems that matter, rather than pointing agents directly at third-party or community servers whose contents you don't control and whose descriptions can change without your review.
- Keep permission enforcement in the resource server, never in the MCP layer or the model's judgment. Use short-lived, scoped tokens issued per call rather than a long-lived static credential wired into the server's configuration - the 2026 spec's closer alignment with OAuth 2.1 makes this materially easier to implement correctly.
- Log every tool call and its arguments centrally, across every server in use, so that a compromised or misbehaving server can't also be the only place evidence of the problem would have existed.
- Scan your MCP surface on a schedule. Tools such as Invariant Labs'
mcp-scancheck for known poisoning and shadowing patterns; treat exposing a new tool to an agent as a reviewed change, not a toggle in a config file. - Treat content returned by any tool call as untrusted input, and keep the actions that actually matter - an outward write, a data export, anything irreversible - behind an approval step that no tool description, however convincingly worded, can grant on its own.
When MCP is the wrong tool
MCP earns its complexity at N times M - many possible clients, many possible systems - not at one client talking to one system. If you have a single agent, a single internal system, and no near-term plan to add a second client or a second tool, a direct, narrow integration is usually simpler to build, secure, and reason about than standing up a general protocol server for an audience of one. The interface question matters more than the protocol: as covered in making an existing system agentic without a rewrite, the API, queue, or adapter you already have may already be the right integration point, and doesn't need to be re-expressed as an MCP server purely because MCP is the current default.
The overhead is also worth weighing in latency- and resource-constrained contexts, such as inference running on-device inside a mobile app. MCP is designed for a host application orchestrating calls out to external servers over a network transport; it isn't built for the tight, compiled loop of a model running locally on a handset, where the cost of general-purpose runtime tool discovery is unlikely to be worth what it buys you. And adopting the protocol doesn't, by itself, make a feature engineered into the product rather than bolted onto it - the same questions about identity, evidence, and recoverable state apply whether a tool call happens through MCP or through a hand-rolled integration.
Frequently asked questions
Is MCP itself a security control?
No. MCP standardises how a tool contract is declared and discovered; it doesn't enforce anything about who may call a tool or what that tool is allowed to do. The security properties come from how the server behind the protocol is built - permission checks enforced independently of the model, identity carried per call, and every attempt logged. A well-designed MCP server can be very safe, and a badly designed one can be dangerous, in exactly the same ways a hand-rolled API can be either.
Should we build our own MCP servers, or use the ones vendors already provide?
Both have a place, but they carry different risk. A vendor- or community-maintained server is convenient, but its tool descriptions and behaviour can change on a schedule you don't control, so it deserves the same scrutiny you'd give any third-party dependency with write access to your data. For systems where the data or the actions matter, building and controlling your own server - even a thin one - gives you a reviewable artefact instead of a moving target.
Does adopting MCP lock us into one AI vendor?
The opposite is closer to true. Because MCP is a vendor-neutral standard now governed through the Linux Foundation's Agentic AI Foundation, a server built to the specification can generally be called by any compliant client, regardless of which model sits behind it. That portability is a large part of why the standard spread as quickly as it did.
How is this different from just calling our existing internal API directly?
Mechanically, not by much - MCP is closer to a shared convention for describing and discovering a tool contract than to a new kind of integration. The difference shows up when more than one client needs to reach the same system, or more than one system needs to be reachable from the same agent: at that point, a standard interface saves you from writing the same discovery and invocation logic repeatedly. If you only ever have one of each, a direct API call is often simpler, and the governable-interface question matters more than which protocol carries the call.
MCP is infrastructure, not a decision. It changes how a tool contract gets written down and discovered - it doesn't tell you which operations belong in that contract, who should be trusted to call them, or what should happen when a call fails halfway through. Those are the questions worth resolving before a protocol choice either way. If you're weighing whether to expose your systems to an agent through MCP, talk to us.
