What Is MCP (Model Context Protocol)? A Complete 2026 Guide

MCP, the Model Context Protocol, is an open standard for connecting AI applications to the systems where data and tools actually live. Instead of every AI product building a bespoke integration for every service it wants to reach, both sides implement one protocol and any compliant client can talk to any compliant server.

Anthropic introduced it in November 2024 and, on 9 December 2025, donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. That governance move is the reason MCP is worth learning rather than waiting out. It is no longer one vendor's protocol.

Why does MCP exist?

The problem MCP solves is combinatorial, and it has a name in integration work: the N times M problem.

If you have N AI applications and M systems they need to reach, bespoke integration means building and maintaining N times M connectors. Ten AI tools and twenty internal systems is two hundred integrations, each with its own auth handling, error semantics, and versioning.

A shared protocol collapses that to N plus M. Each AI application implements the client side once. Each system exposes a server once. Any client can then reach any server.

This is the same argument that produced the Language Server Protocol for code editors, and MCP borrows its structure directly, including JSON-RPC as the message format.

The scale it reached is the evidence it worked. As of the Foundation announcement there were more than 10,000 active public MCP servers, and the protocol had been adopted by ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code, with deployment support from AWS, Cloudflare, Google Cloud, and Microsoft Azure.

How does MCP work?

The architecture has three roles, and confusing them is the most common source of misunderstanding.

The host

The host is the AI application the person actually uses: Claude Desktop, an AI-enabled IDE, ChatGPT, or an internal agent platform. Google Cloud's explainer describes it as the environment containing the model, and the point where the user interacts.

The host holds a critical responsibility that is easy to miss: it is where consent lives. The specification is explicit that hosts must obtain explicit user consent before exposing user data to servers.

The client

The client is a connector inside the host. Each client maintains a one-to-one connection with a single server. A host running five MCP servers is running five clients.

This one-to-one design is deliberate. It keeps a compromised or misbehaving server isolated to its own connection rather than giving it visibility into the rest of the session.

The server

The server is a program that exposes a specific system's capabilities over the protocol. A GitHub server exposes repositories and issues. A Postgres server exposes queries. A Slack server exposes channels and messages.

Servers are usually small. WorkOS's breakdown of server internals shows most of the work is mapping an existing API surface onto the protocol's three primitives, not building new logic.

What can an MCP server actually expose?

The protocol defines three primitives, and the distinction between them carries real design weight.

Tools are the primitive that gets attention, because they let a model act rather than only answer. They are also where the risk concentrates, since a tool call has effects in a real system.

Resources are underused. Loading a schema or a policy document as a resource is often a better answer than giving the model a tool to go fetch it, because the content lands in context deterministically rather than depending on the model choosing to call something.

Prompts are the least implemented of the three, and mostly serve as user-invoked shortcuts.

Zuplo's server guide and Databricks' overview both note the same practical pattern: a well-designed server exposes a small number of well-described tools rather than mirroring an entire REST API. Models choose badly among fifty near-identical tools.

How do clients and servers connect?

Two transports matter in practice.

Standard input and output runs the server as a local subprocess of the host. It is the simplest option, it requires no network exposure, and it is how most desktop integrations work. The constraint is that the server has to run on the same machine as the host.

Streamable HTTP runs the server as a remote service the host connects to over the network. This is what makes hosted, multi-user, and enterprise deployments possible, and it is why Cloudflare and the major clouds now offer MCP server hosting. It also introduces every consideration you would expect of a network service: authentication, authorization, transport security, and rate limiting.

The current specification revision is versioned by date, and the protocol has moved quickly. If you are implementing against it, check the revision rather than relying on a tutorial written a year ago.

MCP compared with the alternatives

Function calling and MCP are frequently confused. Function calling is a model capability: the model emits a structured request to call something. MCP is a transport and discovery protocol: it is how the application finds out which functions exist and routes the call to whatever implements them. They compose. The model still emits a function call, and MCP is what makes that function available without hardcoding it.

What are the security risks?

This is the part most introductions skip, and it is the part enterprise buyers care about most.

Tool poisoning. A server's tool descriptions are read by the model as instructions. A malicious or compromised server can write descriptions that manipulate the model's behaviour, including instructing it to misuse other tools in the same session. The tool description is an untrusted input, and it is easy to forget that because it reads like configuration.

Prompt injection through returned data. A tool returns content from a real system, and that content may contain text crafted to steer the model. A document, an issue comment, or an email body can carry instructions. Any agent that acts on tool results without treating them as untrusted data is exposed.

Excessive scope. MCP servers commonly authenticate with a single credential covering everything that system can do. If the server is reachable by an agent that a user can steer, the agent's effective permissions are that credential's permissions, not the user's.

Supply chain. With more than 10,000 public servers, installing one is running someone else's code against your data. The trust question is the same as any dependency, and the ecosystem is younger than most.

Confused deputy. The agent has legitimate access; the request originates from somewhere less trusted. Without per-request authorization, the agent becomes a path around access controls that would otherwise apply.

None of these are reasons to avoid MCP. They are reasons to treat a server the way you would treat any service with production credentials: reviewed, scoped, logged, and preferably run by someone accountable. Teams working through this properly usually end up connecting it to their broader data privacy and compliance posture rather than treating it as a developer convenience.

Should you build an MCP server?

Build one if you have a system with a real API and multiple AI applications that need to reach it. That is the case the protocol was designed for and it pays off quickly.

Do not build one if the answer is a resource rather than a tool. If what the model needs is a document or a schema, expose it as a resource or put it in context directly. A tool that fetches a static file adds a decision the model can get wrong.

Some practical guidance that holds up:

• Expose few tools, described precisely. Model tool-selection accuracy falls sharply as the count grows and the descriptions converge.
• Make tool names unambiguous. `create_jira_issue` beats `create`, particularly when several servers are connected at once.
• Return structured, compact results. Every token a tool returns is paid for and competes for context.
• Scope credentials to the minimum. Per-user auth where the platform supports it, not one shared token.
• Log every call. You will need the trail the first time an agent does something surprising, and agent performance tracking depends on it.

If you want a worked example of connecting servers to a specific host, the ChatGPT MCP walkthrough and Claude Code MCP server roundup both cover setup in detail.

What does an MCP interaction actually look like?

Walking one request end to end makes the roles concrete.

A user in an AI application types: "What changed on the billing service this week, and is anything still open?"

1. Discovery. When the host started, each client connected to its server and asked what it offers. The GitHub server replied with tools such as `list_commits` and `search_issues`. The host now holds those descriptions and passes them to the model as available capabilities.
2. Selection. The model reads the question and the tool descriptions and decides `list_commits` is relevant, emitting a structured call with a repository name and a date range.
3. Consent. The host checks whether this tool is permitted. Depending on configuration it runs, or it stops and asks the user to approve.
4. Routing. The client forwards the call to the GitHub server as a JSON-RPC message.
5. Execution. The server translates the call into a real GitHub API request using its configured credential, and returns a compact structured result.
6. Continuation. The model receives the result and decides whether it has enough. Here it does not, so it calls `search_issues` for open issues on the same service, and only then answers.

Two things in that sequence deserve attention. Step 2 is a model judgement, which is why tool descriptions are part of your prompt surface rather than documentation. And step 5 returns untrusted content: if an issue title contains instructions, they arrive in context looking exactly like data the model was asked to consider.

What do teams get wrong when adopting MCP?

The failure patterns are consistent enough to be worth naming.

Connecting too many servers at once. Tool-selection accuracy degrades as the count grows. An agent with sixty tools available picks worse than one with eight, and the wrong pick is often silent rather than an error. Start narrow and add on evidence.

Mirroring an entire REST API. A server that exposes forty endpoints as forty tools is technically complete and practically unusable. Expose the handful of operations that map to things people actually ask for, and compose the rest inside the server.

Treating tool descriptions as documentation. They are prompt text. They are read by the model on every turn, they cost tokens, and they determine selection accuracy. Write them for the model, with explicit statements of when not to use the tool, not just what it does.

Assuming retrieval equals understanding. Connecting a Slack server does not mean an agent understands your decisions. It means it can search messages. The gap between those two is the subject of the next section and it is the most common source of disappointment after a technically successful rollout.

Skipping the credential question. The quickest path to a working server is one admin token. That token then defines what every agent using it can do, for every user, permanently. It is worth the extra work at setup to avoid discovering this during an audit.

Not versioning the server. Tools change. Renaming or altering a tool's behaviour changes model behaviour in ways that are hard to attribute later. Treat the tool surface as an API contract with the model as its consumer.

How do you run MCP in an enterprise?

Connecting a server on a laptop is a five-minute job. Running MCP across an organization is a governance exercise, and the teams doing it well converge on a similar shape.

Curate a registry rather than letting servers spread

The failure mode is every engineer installing whatever server solves their immediate problem, each with its own credential. Within a quarter nobody can answer which systems are reachable by which agents.

The fix is an internal registry: an approved list, each entry reviewed, with a named owner and a documented credential scope. The reference implementations and server catalogue are a reasonable starting point for what to review, but "it is in the public list" is not an approval.

Prefer remote servers with per-user auth

Local subprocess servers inherit whatever credentials the developer has. Remote servers over streamable HTTP can authenticate the individual user and scope the response to what that person is allowed to see.

This matters more than it first appears. An agent answering a question about revenue should return different results for a regional sales rep and the CFO. A server holding one shared service credential cannot make that distinction, so the access control silently disappears at the protocol boundary.

Log at the call level, not the session level

Session logs tell you an agent ran. Call logs tell you which tools it invoked, with what arguments, against which system, and what came back. Only the second is useful during an incident, and it is the input to any meaningful review of what agents are actually doing.

Decide the human-approval boundary deliberately

Some tool calls should never run unattended. Writes to production systems, anything customer-facing, anything financial. The approval boundary is a policy decision that belongs to the business, not a default that ships with a server. Most hosts, including Claude Code, support per-tool permission prompts, and the point of configuring them is that the boundary is explicit rather than incidental.

How does MCP fit with agent frameworks and gateways?

MCP is one layer in a stack that people frequently collapse into a single word.

The model generates the response and decides which tools to call. A gateway governs which model answers and what the call costs, which is a separate concern covered in the LLM gateway guide. MCP determines what the model can reach. An agent framework determines what happens across multiple steps: state, retries, branching, and when the task is finished.

These are complements, not competitors. A production system commonly has all four. Confusion arises because vendors in each layer describe themselves as solving "AI integration," which is true of each in a different sense.

The practical consequence is that adopting MCP does not replace agent orchestration, and adopting an orchestration platform does not remove the need for a connection standard. Evaluate them separately.

Where the protocol is heading

The specification is versioned by date and revises frequently. Recent work has concentrated on the areas enterprise adoption exposed: authorization, better server discovery, and elicitation, which lets a server ask the user a clarifying question mid-call rather than failing.

If you are building against it, track the specification revisions and the getting-started documentation rather than blog posts, this one included. The protocol has moved faster than secondary sources have kept up with, and a tutorial written a year ago will describe a transport that has since been superseded.

What MCP does not solve

MCP is a connection standard. It answers "can the model reach this system." It does not answer "does the model understand this company."

Those are different problems and the gap between them is where most enterprise AI projects stall. An agent with twenty MCP servers connected can query Salesforce, read Jira, and search Slack. It still does not know that the deal in Salesforce was actually lost for a reason discussed in a Slack thread three weeks ago, that the Jira epic was superseded, or that the person asking owns a different territory.

That is organizational context, and it is a memory and graph problem rather than a protocol problem. Retrieval alone does not produce it, because the connections that matter span systems and accumulate over time.

The distinction shows up plainly in evaluation. A team pilots an agent, connects it to six systems through MCP, and finds it answers factual lookups well and judgement questions badly. The instinct is to add more servers. The actual gap is that nothing in the stack holds the relationships between what those systems contain, so every question starts from zero. More access does not fix that, and the second wave of connectors usually makes tool selection worse without improving the answers.

Coworker AI works at that layer. It connects to 50+ tools, maintains organizational memory across them, and runs agents that act on what they find rather than only retrieving it. It also speaks MCP, so your organization's context becomes available inside the AI tools your team already uses instead of being a separate destination. Plans are Pro at $29.99 per user per month, Max at $149.99, and Enterprise pricing on request.

Book a demo if you want to see the difference between an agent that can reach your tools and one that understands your organization.

Frequently asked questions

What is MCP in AI?

MCP stands for Model Context Protocol. It is an open standard that lets AI applications connect to external tools and data sources through one common interface, so each application implements the protocol once instead of building a separate integration for every system it needs to reach.

Who created MCP and who controls it now?

Anthropic introduced MCP in November 2024. On 9 December 2025 Anthropic donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded with Block and OpenAI and supported by Google, Microsoft, AWS, Cloudflare, and Bloomberg. It is now governed by that foundation rather than a single company.

What is the difference between an MCP server and an MCP client?

A server exposes one system's capabilities over the protocol, such as a GitHub server or a Postgres server. A client is a connector inside the AI application that maintains a one-to-one connection with a single server. A host application running five servers runs five clients, one per server.

Is MCP the same as function calling?

No, they compose. Function calling is a model capability where the model emits a structured request to invoke something. MCP is the protocol that discovers which functions exist and routes the call to whatever implements them. MCP is how a tool becomes available without hardcoding it into the application.

What are tools, resources, and prompts in MCP?

Tools are functions the model can call that have side effects, chosen by the model during a turn. Resources are read-only data the host loads into context, such as a file or schema. Prompts are reusable templates the user invokes explicitly. Tools carry the most risk because they act on real systems.

Is MCP secure?

The protocol itself is not the risk; the servers are. The main concerns are tool poisoning, where a server's tool descriptions manipulate the model, prompt injection through data a tool returns, over-scoped credentials, and supply chain risk from installing third-party servers. Treat any MCP server as you would a service holding production credentials.

How many MCP servers exist?

More than 10,000 active public servers as of Anthropic's December 2025 Foundation announcement, spanning developer tools through Fortune 500 deployments. The public catalogue is only part of it, since many organizations run private servers for internal systems.

Does MCP give an AI agent memory of my company?

No. MCP handles access, not understanding. It lets an agent query your systems, but it does not give the agent knowledge of decisions, ownership, or history that spans those systems. That is an organizational memory problem and requires a layer above the protocol.

Related reading

• ChatGPT MCP: How to Connect MCP Servers to ChatGPT
• 12 Claude Code MCP Servers Every AI Team Needs
• What Is an LLM Gateway? Architecture and Cost Control
• AI Agent Orchestration Platforms, and How to Choose
• Agent Workflows Explained
• Enterprise AI Agents: What Business Leaders Need to Know
• Agentic AI vs Generative AI: What Is the Difference?
• 8 Best AI Agent Builders for Enterprise Teams
• 16 Ways to Use AI For Knowledge Management
• Enterprise AI Buyer's Checklist: 10 Questions
• Ensuring Data Privacy Compliance When Using Enterprise AI
• 25 Agent Performance Metrics You Need to Track