MCP, the Model Context Protocol, is an open standard for connecting AI applications to the tools and data they need. An MCP server wraps a system, such as a CRM, a database, a file store or an internal API, and describes what it offers in a standard format. Any AI application that speaks MCP can then use that system without a custom integration for each pair. Anthropic introduced MCP in November 2024 to replace the one-off connectors every AI tool was building, and in December 2025 donated it to the Agentic AI Foundation, a fund under the Linux Foundation. The current specification is version 2026-07-28, checked on 24 October 2026. For a business, the short version is this: build a connector to an internal system once, as an MCP server, and every AI assistant, coding tool or agent you adopt can use it, under the permissions you set.
How MCP works
MCP messages are JSON-RPC 2.0 requests and responses. The architecture has three roles:
- Host: the AI application the user works in, such as a chat assistant, an IDE or your own agent. It runs the model, holds the conversation, asks the user for consent and enforces security policy.
- Client: a connector inside the host. Each client talks to exactly one server, so a host connected to five systems runs five clients.
- Server: a program that exposes one system's capabilities. It can run as a local process on the user's machine or as a remote service.
One design rule matters for buyers. The specification says servers should not be able to read the whole conversation or "see into" other servers. The host decides what each server receives, so a CRM server does not see what the user said to the finance server.
What a server offers: tools, resources and prompts
| Primitive | Who controls it | What it is | Business example |
|---|---|---|---|
| Tools | The model | Functions the model can call to act or fetch data | Create a ticket, look up an order, update a deal stage |
| Resources | The application | Data the host attaches as context | A policy document, a customer record, a file's contents |
| Prompts | The user | Templates the user picks, often as slash commands | "Summarise this account", "Draft a refund reply" |
Tools are where the value and the risk sit, because they let a model take actions. Servers can also ask the client for input mid-request, for example asking the user to confirm a detail (the spec calls this elicitation) or asking the host's model for a completion. Optional extensions add long-running tasks, structured skills and interactive UI inside a conversation (MCP Apps).
Transports: local and remote
The specification defines two standard transports:
- stdio: the host starts the server as a subprocess on the same machine and they exchange messages over standard input and output. This is how most desktop and IDE integrations work. Credentials come from the local environment.
- Streamable HTTP: each message is an HTTP POST to one MCP endpoint, with replies as JSON or a stream. This is how remote, shared servers work, and it is the transport the authorization rules are written for.
What changed in 2026
MCP versions are dates that mark the last backwards-incompatible change (versioning). In version 2026-07-28 the protocol became stateless: every request carries its own protocol version and capabilities, and there is no session handshake. Revisions up to 2025-11-25 used an initialize handshake, and the spec describes how new and old implementations fall back to each other. If a vendor's MCP server or client predates mid-2026, ask which revision it implements.
What MCP changes for a business
Before MCP, connecting three AI tools to four internal systems meant up to twelve integrations, each built to one vendor's plugin format. With MCP it is four servers, one per system, which any compliant host can use. Anthropic's donation announcement in December 2025 reported more than 10,000 active public MCP servers and 97 million monthly SDK downloads, and named ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code among the products that support it. Those are the project's December 2025 figures; we have not seen a newer official count.
In practice that means:
- Connect once, reuse everywhere. A server for your order system serves your support agent, your staff's chat assistant and your engineers' coding tools.
- Less lock-in to one AI vendor. If you switch assistants, the connectors move with you.
- Vendors ship servers for you. Many SaaS products now publish their own MCP servers. Our platform pages note them where they exist, for example HubSpot, Shopify, n8n and Zapier and Make. Use the vendor's server before building your own.
- One place to enforce access. Because every AI tool reaches the system through the same server, permissions, logging and rate limits live in one place.
MCP does not make an agent reliable, choose the right workflow or replace evaluation. It is plumbing. Whether the agent at the other end does useful work is a separate question, covered in what agentic workflows are and what a production agent stack contains.
Security risks and the controls that address them
The specification is direct about the risk: MCP opens "arbitrary data access and code execution paths", and the protocol cannot enforce safety on its own. Its security principles put the duty on implementers: users must consent to data access and actions, hosts must get consent before invoking any tool, and descriptions of tool behaviour should be treated as untrusted unless they come from a trusted server. These are the risks we see most often, with the spec's controls.
1. Prompt injection through tool output. A tool result is text the model reads. If that text comes from an email, a web page or a support ticket, an attacker can plant instructions in it, and the model may follow them with whatever tools it holds. The tools specification says clients should validate tool results before passing them to the model, show tool inputs to the user before calling the server to avoid data exfiltration, and ask for confirmation on sensitive operations. It also says there should always be a human able to deny a tool call. Real incidents, including the GitHub MCP and Supabase cases, are written up in our AI agent security framework.
2. Poisoned or malicious servers. Tool descriptions and annotations are text the model trusts, and a local server is code running with the user's privileges. The security best practices require clients that offer one-click local server setup to show the exact command before running it and get explicit approval, and recommend running servers in a sandbox with minimal privileges. Treat a third-party MCP server as a dependency: review it, pin its version and allowlist it.
3. Over-broad permissions. A server that exposes every scope up front turns one stolen token into access to everything. The security best practices call for scope minimisation: start with a minimal, read-mostly scope and step up only when a privileged tool is first used. In practice, give each agent its own credential, scoped to the narrowest role, and keep write and delete tools separate from read tools.
4. Weak authentication on remote servers. Authorization is optional in the protocol, but when a remote server uses it, it is built on OAuth 2.1. Servers must publish protected resource metadata, clients must name the server a token is for (resource indicators), and servers must validate that a token was issued for them. The spec forbids token passthrough: a server must not accept a token meant for another service or forward the user's token to a downstream API. The best practices also cover confused-deputy attacks on proxy servers, server-side request forgery during OAuth discovery, and hijacking of state handles.
5. No audit trail. The tools specification says servers must validate inputs, enforce access controls, rate limit and sanitise outputs, and that clients should log tool usage. If you cannot answer "which agent called which tool, with what arguments, on whose behalf" after an incident, the integration is not ready for production.
When to build an MCP server and when a plain API integration is better
MCP earns its keep when several AI clients need the same system, or when you want the model to choose which actions to take. A fixed automation that calls one API in a known order gains little from it. This is our rule of thumb:
| Situation | Better choice | Why |
|---|---|---|
| Several AI tools (assistant, coding tool, your agent) need the same internal system | MCP server | Build once; every compliant host can use it |
| The vendor already publishes an MCP server | Use the vendor's server | Maintained by the people who own the API |
| A fixed workflow: trigger, call an API, write a record | Plain API integration | No model chooses the steps, so tool discovery adds nothing |
| One agent, one system, tight latency or cost budget | Direct function calling in your agent | Fewer moving parts; move to MCP when a second client appears |
| Staff should reach internal data from the AI assistant they already use | MCP server (remote, with OAuth) | Users keep their own identity and permissions |
| High-risk writes (payments, deletions, customer messages) | Either, behind an approval step | The control matters more than the protocol |
If you are deciding between a rules-based automation and an agent in the first place, start with rules-based automation vs AI agents.
MCP vs A2A
A2A (Agent2Agent) solves a different problem. MCP connects an agent to tools and data. A2A connects one agent to another agent as a peer, so they can discover each other, hand over a task and return results without sharing their internal memory or tools. The A2A specification, version 1.0 as checked on 24 October 2026, defines an Agent Card (a JSON description of an agent's skills, endpoint and authentication), Tasks with a lifecycle, and Messages, Parts and Artifacts for the content exchanged. It runs over JSON-RPC, gRPC or HTTP+JSON.
A2A's own specification says the two are complementary: an agent receives a task over A2A and uses MCP to reach the tools it needs to do it. Most businesses need MCP first. A2A matters when you run several agents, possibly from different vendors, that have to delegate work to one another.
A buyer's checklist for MCP
Copy this into your vendor questionnaire or your own design review.
Fit
- [ ] We can name the AI clients that will use this server (assistant, coding tool, our agent), and there is more than one, or will be within a year.
- [ ] We checked whether the system's vendor already publishes an MCP server, and why we are not using it.
- [ ] We know which revision of the spec the server and each client implement (2026-07-28 or an earlier handshake-based revision).
Scope and permissions
- [ ] Every tool is listed with what it reads, what it writes and whether it can be undone.
- [ ] Read tools and write tools are separate, and destructive tools (delete, refund, send) are either absent or behind a human approval step.
- [ ] Each agent or user gets its own credential with the narrowest scope it needs; there is no shared admin key or service-role key.
- [ ] Scopes start minimal and step up when a privileged tool is first used.
Authentication
- [ ] Remote servers use OAuth 2.1 as the spec describes: protected resource metadata, resource indicators and audience validation.
- [ ] The server never accepts a token issued for another service and never forwards the user's token downstream.
- [ ] Local (stdio) servers take credentials from the environment, not from a config file committed to a repository.
Untrusted content
- [ ] We have listed which tools return content written by outsiders (emails, tickets, web pages, documents).
- [ ] Sessions that read outside content cannot also send data out without confirmation.
- [ ] Tool results are validated before the model sees them, and tool inputs are shown to the user for sensitive calls.
- [ ] Third-party servers are allowlisted, version-pinned and reviewed before upgrades.
Operations
- [ ] Every tool call is logged with the agent, the user it acted for, the arguments and the result.
- [ ] Tool calls have timeouts and rate limits.
- [ ] Someone owns the server, its updates and its incident response.
- [ ] We have tested what happens when the server is down or returns an error.
Getting it built
Plenty of teams need nothing custom: switch on the MCP servers your vendors already publish, apply the checklist and stop there. When the system is your own (an internal API, a legacy database, a back-office tool), someone has to build the server and the controls around it. Our AI integration work covers that. One workflow, with integration to up to three tools, is the AI Quick Win Sprint at $8,000 fixed over 3 weeks, and whether each integration is an MCP server or a direct API call is decided with you using the table above. A production agent that uses those connections is a Gigabit Agents build, from $8,000 flat per agent. If you already run agents with MCP access and need them tested for prompt injection and excessive agency, our AI Security Assessment starts at $12,000.
