Model Context Protocol (MCP)

What is MCP?#

MCP, or Model Context Protocol, standardises how AI applications communicate with external tools and data sources. It gives applications a common way to discover available capabilities, send requests and receive results, without requiring a separate integration for every service.

Before MCP, an AI application that needed access to GitHub, a database and an internal application generally required separate integrations for each. Every additional application and service created more integration work. MCP addresses this by defining an interface that compatible applications and servers can share.

The official MCP documentation compares it to USB-C: different devices can connect through the same interface instead of requiring a proprietary connection for each one.

The comparison explains interoperability, although connecting an AI application to an external system creates challenges that a physical connector does not have. An MCP connection can work exactly as intended while the server consumes excessive context, exposes sensitive information or returns content that influences the agent's next action.

MCP standardises the communication layer, including JSON-RPC messages, capability discovery, supported transports and an optional authorisation framework. The design and governance of those capabilities remain largely the responsibility of the people building and operating them.

MCP was created by David Soria Parra and Justin Spahr-Summers at Anthropic and released under the MIT licence on 25 November 2024. The protocol gained support from OpenAI, Microsoft, AWS and Google within five months, and Anthropic donated it to the Agentic AI Foundation under the Linux Foundation on 9 December 2025.

That adoption has made MCP a common interface for agent tooling, but organisations still need to decide which servers to trust, which operations agents may perform and how their activity should be monitored. Connecting a server is relatively straightforward. Managing the context cost, permissions, dependencies and audit trail becomes more complicated as the number of connections grows.

The distinction becomes clearer when looking at how an MCP server interacts with the application that uses it.

What is an MCP server?#

An MCP server is a program that makes tools, data or reusable prompts available to an AI application through the Model Context Protocol.

Most MCP servers provide access to capabilities that already exist in another system. A GitHub server, for example, can expose repository operations through GitHub's API. A database server can offer controlled query capabilities, while an internal server can give agents access to company services.

The server can run locally as a subprocess or remotely as a service. What it makes available depends on the underlying system, the implementation and the permissions granted to the connection.

MCP uses a host-client-server architecture, with responsibilities divided between three components. The host is the AI application itself, such as Claude Code, an IDE or a custom agent. Inside the host, an MCP client manages the connection to a particular server. Each client communicates with one server, while the host can manage several clients simultaneously.

Source: MCP architecture specification, 2026-07-28.

A typical exchange starts with discovery. The client sends a tools/list request, and the server replies with each tool's name, description and input schema, which the host passes to the model. When the model decides a tool is needed, the client sends a tools/call request with the tool name and its arguments. The server translates that call into the underlying system's own interface, such as a REST request or a database query, and returns the result, which the host adds to the model's context. Resources and prompts follow the same pattern through resources/list and resources/read, and prompts/list and prompts/get.

All of these are JSON-RPC 2.0 messages. Under the current revision, each request carries its protocol version and the client's capabilities, so no handshake has to come first.

The host manages permissions and coordinates information from the connected servers. This allows an agent to retrieve an issue from one server, inspect a repository through another and submit a change through a third, all within the same application.

Although each client maintains a separate server connection, the model can use information from one connection to decide what to do with another. An agent might read an issue description and then use its repository permissions to make a code change. The host therefore needs to manage both access to individual capabilities and the consequences of combining them within a workflow.

How does MCP work?#

MCP gives applications a standard method for discovering a server's capabilities and interacting with them. The client and server exchange JSON-RPC messages over a supported transport, allowing the application to retrieve information or request operations without having to understand the underlying service's proprietary interface.

When an application connects to a server, it can discover the capabilities available and decide how to present them to the model or user. The specification groups these capabilities into three primitives: tools, resources and prompts.

Source: MCP specification, 2026-07-28, server features.

These primitives differ in who decides when they are used. A resource can be selected by the application, while a prompt is typically invoked by the user. Tools, however, are model-controlled, so the decision to call one may depend on the model recognising that it is appropriate.

This has practical consequences for workflow design. If an agent has access to a validation tool, it may choose to run it after changing code. But having the tool available does not guarantee that the model will call it. Jaime Jorge made the same point on our podcast: "just leveraging an MCP alone requires the AI model to want to call those things at those particular moments. So that's not enough."

A validation step that must run after every change is better enforced through a deterministic pipeline. MCP can provide access to the underlying tool, while the pipeline ensures that the required check happens regardless of the model's decisions.

Transports and protocol revisions

MCP supports two transports. stdio exchanges messages through the standard input and output streams of a subprocess, making it suitable for local servers. Streamable HTTP supports remote connections through HTTP requests, with responses returned as JSON or a request-scoped Server-Sent Events stream.

The protocol has changed substantially since its initial release. Its five revisions are 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25 and the current 2026-07-28.

The 2025-03-26 revision replaced HTTP+SSE with Streamable HTTP. A larger architectural change arrived on 28 July 2026, when MCP became stateless at the protocol level.

That revision removed the initialize / notifications/initialized handshake, protocol-level sessions and the Mcp-Session-Id header. Requests now carry their protocol version and client capabilities, allowing servers to process them without relying on shared session state. Roots, Sampling and Logging were also deprecated.

Older MCP tutorials may still describe the handshake-based approach, and implementations supporting previous revisions can behave differently from those following the latest specification. Before building an integration, it is worth checking the specification versioning documentation and the relevant revision's implementation requirements.

How MCP handles authorisation

MCP's authorisation framework is optional. HTTP implementations should follow the specification's authorisation requirements, while local stdio implementations commonly receive credentials through their environment.

Where OAuth is used, the specification includes an audience restriction intended to prevent credentials from being accepted by the wrong service. Servers "MUST validate that access tokens were issued specifically for them as the intended audience".

This prevents a token intended for one MCP server from being replayed against another. Organisations still need to manage the permissions associated with those tokens, how credentials are stored and rotated, and whether a particular agent should be allowed to perform a requested action.

How is MCP different from an API, RAG and function calling?#

MCP is often compared with APIs, function calling and retrieval-augmented generation because all three can help AI applications interact with external systems. They serve different purposes, however, and are frequently used together.

An API exposes the operations a service makes available. MCP can provide a standard interface through which an AI application discovers and accesses those operations. Function calling allows a model to request an operation, while retrieval-augmented generation supplies relevant information for the model to use.

Sources: MCP specification; Google, A2A introduction; re:cinq engineering comparison.

For many engineering tasks, a conventional API or command-line interface remains sufficient.

If an agent already has shell access and the required tool offers a CLI, adding an MCP server may introduce extra complexity without much benefit. Armin Ronacher compared GitHub operations through MCP and the gh CLI, finding that the command line "uses context far more efficiently".

His analysis raises a reasonable question for teams considering MCP: does the additional integration layer make the workflow easier to operate, or does it introduce overhead that the task does not require?

MCP becomes more attractive when the client cannot execute arbitrary commands, when capabilities need to be discovered dynamically, or when multiple applications should use the same integrations through a common authorisation and audit path.

How does MCP compare with A2A?

The A2A protocol, or Agent2Agent, addresses communication between agents rather than access to tools.

Google introduced A2A on 9 April 2025 as a complementary protocol. It allows agents operating across different systems or organisations to discover one another, communicate and delegate work. MCP, by comparison, provides access to the capabilities an individual agent needs while performing its own tasks.

A workflow can use both. One agent might delegate a task to another through A2A, while each agent uses MCP to interact with its own repositories, databases or services.

Google donated A2A to the Linux Foundation in June 2025. IBM's agent communication protocol, originally developed through IBM Research and the BeeAI community, merged into A2A under the Linux Foundation in August 2025 and is no longer developed as a separate protocol.

For teams beginning with agents, tool integration usually comes before coordination between independent agents. That makes MCP a natural first implementation, provided the additional integration layer is actually needed.

How much context does an MCP server cost?#

Every capability exposed to a model through MCP needs a description explaining what it does and how to call it. These descriptions occupy space in the model's context window, even when the agent never uses the tools.

Many MCP clients load tool definitions before a conversation begins. The more tools a server exposes, the more context can be consumed before the model starts working on the user's request.

This becomes expensive when an MCP server is generated directly from a large REST API. Each endpoint may be exposed as a separate tool, complete with descriptions and input schemas, even when several endpoints perform closely related operations.

Bogdan Szabo encountered this while building an MCP integration at re:cinq. Starting with an API containing 25 data models and 6 operations, an automatically generated server exposed 150 tools. One tool definition contained nearly 1,200 tokens, and the full set consumed roughly 75,000 base tokens before any conversation had started.

He then redesigned the integration around the capabilities the agent actually needed. Instead of exposing every model-operation combination, the server offered generic operations with the relevant model selected through a parameter. Schemas could be retrieved when needed.

The result was 8 tools requiring about 1,500 tokens.

"With MCP, the size of your API is your most expensive cost." Bogdan Szabo, re:cinq

Source: Bogdan Szabo, Simple Tools, Smarter Agents, re:cinq, 9 April 2026.

The redesign reduced the base tool-definition cost by 98%. It also left the model with fewer overlapping operations to choose between, making the interface easier to navigate.

Anthropic reported a similar direction of improvement in its code execution with MCP article from November 2025. In one worked example, moving MCP tool interactions into generated code reduced consumption from 150,000 tokens to 2,000, described as "a time and cost saving of 98.7%".

That figure comes from a single scenario without a stated methodology or tool inventory. It illustrates what code execution can achieve, but does not establish how much any particular deployment will save.

Both examples demonstrate how large tool definitions can consume context before the agent begins its task, with intermediate results adding further overhead during execution.

Reducing that overhead may involve lazy discovery, more compact capability design or code execution. But code execution introduces its own requirements for sandboxing, resource limits and monitoring, so the context savings need to be weighed against the infrastructure required to obtain them.

The available evidence also has limitations. No neutral, reproducible public measurement of MCP tool-definition cost exists. The published figures come from interested parties, including Anthropic, re:cinq and vendors offering related solutions.

If context consumption materially affects an architectural decision, measure the tool definitions and resulting usage in your own client. This will tell you how much of the model's capacity is being consumed by connected capabilities and whether those capabilities justify the cost.

What are the main MCP security risks?#

An MCP connection can give an agent access to external data, executable operations and credentials. The security risks extend across the entire connection, from the software package that provides a server to the instructions an agent encounters while using it.

Four publicly documented incidents illustrate how different those failures can be.

Sources: Invariant Labs, 26 May 2025; Asana customer disclosure reported by The Register, 18 June 2025; Check Point Research, 5 August 2025; Koi Security, reported by The Register, 29 September 2025.

Only the Cursor incident involved a defect in MCP client code. The remaining cases concerned untrusted instructions, server implementation and package provenance.

The GitHub incident is particularly revealing because the server itself was functioning as designed. The agent had legitimate access to both public and private repositories. An attacker placed instructions inside a public issue, where the agent encountered them while carrying out its assigned task. The agent then used its existing permissions to access and publish private information.

Invariant Labs described the incident as "not a flaw in the GitHub MCP server code itself".

The attack worked because instructions embedded in untrusted content influenced the agent's behaviour. The agent was authorised to read the issue and access the private repository, but the content of the issue should not have been treated as an authority governing how those permissions were used.

This risk exists wherever an agent reads material it does not control while holding credentials for more sensitive systems. Fixing the GitHub server would not eliminate the underlying problem.

OWASP classifies this broader risk under ASI01 Agent Goal Hijack in its Top 10 for Agentic Applications 2026. Its summary describes the GitHub case as tool-descriptor poisoning, although Invariant's original finding concerns instructions embedded in retrieved content. Those mechanisms should be distinguished.

The postmark-mcp incident exposed another weakness: installing an MCP server is a software supply-chain decision, particularly when the server can access sensitive systems or credentials.

The malicious package imitated a legitimate integration and established apparent credibility over fifteen releases before introducing behaviour that copied outgoing emails to an attacker-controlled address. Postmark confirmed that it "had absolutely nothing to do with this package".

Idan Dardikman of Koi Security described what teams were doing: "We're handing god-mode permissions to tools built by people we don't know, can't verify, and have no reason to trust." OWASP covers this category under ASI04 Agentic Supply Chain Vulnerabilities, which includes "Compromised MCP / Registry Server".

These incidents show why securing MCP requires attention to the entire workflow. Organisations need to evaluate server provenance, dependency management, tool permissions, data isolation and how agents interpret content returned by connected systems.

What does the NSA recommend for MCP security?

In May 2026, the NSA published Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation, a Cybersecurity Information Sheet from its AI Security Center.

The guidance makes nine recommendations: select supported MCP projects where possible, design around security boundaries, validate tool parameters, constrain and sandbox execution, sign and verify messages, filter and monitor chained outputs, instrument logging and detection, track and patch vulnerabilities, and scan local networks for exposed or vulnerable servers.

Its assessment of credentials is particularly relevant. The NSA notes that MCP servers "rely on bearer tokens, as defined in OAuth 2.1, without specifying protocol-level token lifecycle management".

The protocol establishes token-validation requirements, but implementations remain responsible for expiry, rotation and other lifecycle controls.

Logging presents a similar concern. The NSA found that many implementations "either omit logging entirely or record only minimal operational metadata".

Basic connection logs may tell an administrator that a server was called, while providing little insight into what the agent requested or which information influenced its next action. Investigating an incident may require the tool name, parameters, user identity, agent identity and the subsequent operations performed.

The NSA also recommends discovering MCP servers running outside approved change control. Engineers can install local or third-party integrations without involving the teams that normally review enterprise dependencies, which makes it difficult to maintain an accurate inventory.

For an organisation deploying MCP at scale, security therefore includes knowing which servers exist, who owns them, what permissions they hold and how their behaviour can be reconstructed after an incident.

What are the main criticisms of MCP?#

MCP has gained widespread support, but engineers using it for substantial workloads have raised concerns about its context consumption, composability and limited treatment of operational risk.

Armin Ronacher identified two problems after evaluating MCP for agentic coding. He argued that "It isn't truly composable. Most composition happens through inference" and that "It demands too much context".

The composability concern comes from how models select tools. In a shell script, two commands can be chained in a defined sequence. In a workflow built from model-selected MCP calls, the model may need to infer which operation to call next.

That flexibility can work well for exploration, where the sequence of actions depends on what the agent discovers. For processes that require a particular step every time, relying on inference introduces uncertainty that a deterministic workflow would avoid.

The context problem follows from the way tool definitions are presented to the model. A server may expose dozens of capabilities, each requiring a description and schema. The model consumes those definitions even if the task only needs one or two of them.

Shrivu Shankar explored several additional limitations in Everything Wrong with MCP, published in April 2025.

The specification has no native concept of tool risk. A read-only operation and a destructive write may be exposed through the same mechanism, leaving the application or surrounding infrastructure to determine their relative sensitivity.

MCP also lacks a standard way to declare the expected cost of an operation. A tool call might return a short result or a megabyte of data, with different consequences for context usage and subsequent model calls.

Another concern is the ability of server descriptions to change after a connection has been approved. This can allow a trusted-looking tool to present different behaviour later, a risk illustrated by the Cursor configuration vulnerability.

Cloudflare's engineers raised a related question about how large tool collections should be presented to language models. In their Code Mode article, they observed that models have extensive experience generating code but much less experience selecting from large collections of specialised tool calls.

Their argument is that models can sometimes interact more efficiently with a broad API when they write code against it, instead of choosing from a long list of individual tools.

Anthropic has made a similar argument in its work on code execution with MCP. Both companies offer products or services associated with their proposed approaches, so their conclusions should be read with that commercial context in mind.

None of these criticisms removes the benefit of a common connection format. Runtime discovery, shared integrations and a consistent foundation for authorisation can reduce integration work across applications.

They do, however, affect how MCP should be designed and deployed. A larger number of available tools does not necessarily improve an agent's performance, especially when those tools consume context, overlap in purpose or introduce additional decisions for the model to make.

What is an MCP gateway?#

An MCP gateway sits between AI applications and the servers they use, providing a central place to manage connections, credentials, permissions and logging.

As MCP adoption grows, managing these controls separately for every agent and server becomes increasingly difficult. A single agent might connect to a repository, an issue tracker and an internal database, each with different credentials and access requirements. Across hundreds of developers, these integrations can become difficult to inventory and govern consistently.

A gateway can route those connections through a shared control layer, allowing an organisation to apply policies without requiring every application to implement them independently.

Aonan Guan described this enterprise pattern in an Agentic AI Foundation analysis published in August 2026.

In the software factories we run with clients, the gateway approach centres on three controls.

Credentials are held by the gateway rather than exposed directly to the agent. Permissions are evaluated for individual tools, allowing read operations and destructive actions to be governed differently even when they belong to the same server. Calls are recorded with their parameters and the identity responsible, providing evidence for investigations and operational monitoring.

These controls can make MCP connections easier to govern, but the gateway introduces another component that must be implemented and secured correctly.

The MCP specification does not define a gateway as a standard architectural component. Its nearest concept, an MCP Proxy Server, is discussed primarily in relation to security risks, including confused-deputy attacks and token passthrough.

The MCP security best practices state that servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server". A gateway that forwards a caller's token to an upstream service without the correct audience restrictions can violate that requirement.

The NSA has also expressed caution about MCP-aware security infrastructure. Its guidance says these proxies "remain limited and are still maturing, but may offer partial mitigations", and that they "should be used with caution, especially when handling sensitive data".

Several vulnerabilities have already been identified in gateway implementations.

In agentgateway, a protocol-translation flaw, CVE-2026-29791, allowed tool arguments to influence upstream paths and headers. Related findings included policy-inspection bypass through request-body truncation and MCP session reuse across backends, with the latter rated CVSS 8.1.

The Agentic AI Foundation's analysis found the same kind of translation flaw across Higress, agentgateway, LiteLLM and Unla, indicating that the problem was not confined to a single implementation.

Gateways also concentrate credentials and traffic into one component, increasing the consequences of a failure in that component.

Available projects include agentgateway, Docker MCP Gateway and IBM ContextForge. Each offers a different approach to aggregation, isolation and integration.

When evaluating them, organisations should examine how credentials are isolated, how policies are applied to tool calls, whether complete requests are inspected and how quickly identified vulnerabilities are resolved.

A gateway can improve access control and visibility, but it cannot determine whether an agent has been influenced by malicious instructions in material it was legitimately allowed to retrieve. That problem remains part of the wider agent and workflow design.

Which MCP servers should you connect?#

The best MCP servers for a team depend on the systems its agents need to access and the work they are expected to perform.

A catalogue with hundreds of available integrations may appear attractive, but every additional server introduces maintenance, permissions and potentially more context consumption. Connections that rarely contribute to actual tasks can become ongoing costs without providing a corresponding benefit.

For software delivery teams, the most relevant integrations are often the repository host, issue tracker, observability platform and selected internal services.

One of our teams used Claude Code with a Jira MCP server to resolve a race-condition bug in about thirty minutes. The work had previously been estimated at two days.

The agent benefited from direct access to the issue information it needed while working. There was no advantage in making unrelated services available for that task.

Server selection becomes more complicated when an organisation has many developers using different agents and configurations.

Each approved server should have a named owner, a known publisher, a recorded version and a process for updates and vulnerability management. The official MCP registry provides a discovery mechanism and verifies publisher namespaces through DNS, but publisher identity alone does not establish whether a package is safe to execute.

The NSA recommends applying stringent code review to MCP projects and maintaining an inventory of versions and patch history.

Context consumption should also be monitored. A server exposing forty tools that an agent uses twice a month may still consume context every time it is connected. Reviewing actual tool usage makes it possible to identify unnecessary connections and simplify interfaces that expose more operations than agents need.

Shared organisational context creates another challenge.

A hand-maintained instruction file can work for a small team, but keeping architectural decisions, conventions and task context consistent becomes harder as more developers and agents are involved.

This was the problem behind Lore, re:cinq's MCP server for organisation-wide context, persistent memory across sessions and a task pipeline. The project is published under Apache 2.0, with its repository available on GitHub.

Maintaining context through a shared, versioned service gives teams a more consistent source of information than relying on separate local files that can drift apart over time.

A manageable MCP environment therefore starts with the work itself. Teams should connect the systems agents genuinely need, review the permissions those connections expose, monitor their context cost and maintain clear ownership of shared infrastructure.

Who governs MCP now?#

Anthropic donated MCP to the Agentic AI Foundation on 9 December 2025, placing the protocol under a directed fund of the Linux Foundation.

The donation included MCP alongside Block's goose and OpenAI's AGENTS.md. The foundation was established to provide shared governance for agent infrastructure used across companies that otherwise develop competing products.

Its platinum members include AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI. The governing board is chaired by David Nalley of AWS.

This structure gives the protocol a development process that extends beyond its original publisher, with specification revisions and technical decisions handled through shared governance.

Sources: MCP specification and release notes; Anthropic; Agentic AI Foundation; NSA Cybersecurity Information Sheet.

MCP's specification revisions use dates in the format YYYY-MM-DD, reflecting the date of the last backwards-incompatible change. Technical articles and integration examples therefore need to be read against the revision they describe, especially when they cover transport behaviour, sessions or authorisation.

Shared governance gives MCP continuity and a formal process for technical changes, while responsibility for individual deployments remains with the organisations operating them.

Those organisations still need to decide which servers to trust, how credentials are managed, what actions agents may perform and what evidence is recorded when something goes wrong.

MCP provides a common interface for connecting AI applications to external systems. How reliably those connections operate depends on the engineering decisions surrounding the protocol, from tool design and context management to security, monitoring and ownership.

What should you read next about MCP?#

Simple Tools, Smarter Agents: How re:cinq reduced one MCP server from 150 tools and roughly 75,000 tokens to 8 tools and about 1,500 tokens.

Lore: An MCP server providing organisation-wide context, persistent memory and task pipeline capabilities.

Google's A2A Protocol: How agent-to-agent communication and delegation complement MCP's agent-to-tool connections.

Slack to Atlassian with n8n and MCP: A worked example of connecting an MCP server to a workflow behind a chat interface.

The Spec Is the Attack Surface: How specification drift and prompt injection affect agentic coding workflows.

Software Factories: The governance, validation and execution infrastructure behind agent-driven software delivery.