MCP: the Model Context Protocol explained

Overview

The Model Context Protocol, usually shortened to MCP, is an open standard for connecting AI applications to the outside world. A model on its own can only read the text it is given and write text back. It cannot look up a customer record, query a database, read a file or open a ticket. MCP defines one common way for an application to offer those abilities to a model, so that the same connector works in many different AI products.

A useful everyday picture is the USB-C port. Before a common port existed, every phone, laptop and camera had its own cable. Each new device meant a new cable, and each cable worked with only a few devices. A shared port changed the arithmetic: a device maker builds one port, an accessory maker builds one plug, and everything fits. MCP plays the same role between AI applications and the systems they need to reach. A team writes one MCP server for its database, and any MCP-capable assistant, coding agent or chat client can use it.

This page explains what MCP is, where it came from, how its parts fit together, how a real request flows, what it is good and bad at, how it compares with other approaches, and how to build and run MCP servers safely in production.

What it is

MCP is a client and server protocol built on JSON-RPC 2.0 messages. It has three kinds of participants.

The host is the AI application the person uses, such as a desktop assistant, an IDE or an agent runtime. The host owns the conversation and the model.
The client is the connector inside the host that speaks MCP. A host creates one client per server it connects to.
The server is a program that exposes capabilities. It might wrap a database, a SaaS API, a file system, a search engine or an internal service.

A server can offer three main kinds of things, called primitives.

Primitive	Who controls it	What it is	Example
Tools	The model	Functions the model can decide to call, with a name, a description and a JSON Schema for the input	`create_ticket`, `run_sql`, `search_docs`
Resources	The application	Read-only data the host can attach as context, addressed by a URI	A file, a table schema, a log excerpt
Prompts	The user	Reusable prompt templates the person can pick, often shown as slash commands	"Summarise this incident", "Review this pull request"

The distinction between the three matters. Tools are actions the model chooses. Resources are context the application chooses to include. Prompts are workflows the person chooses to start. Keeping these roles apart gives each party clear control.

Clients can also offer features back to servers. Sampling lets a server ask the host's model for a completion, so the server does not need its own model key. Elicitation lets a server ask the person for a missing value, such as a date range or a confirmation, through the host's interface. Roots tell a server which folders or locations it is allowed to work in.

Where it came from

Anthropic introduced MCP as an open specification in November 2024, together with SDKs and reference servers. The problem it addressed was already familiar to anyone building AI products: every assistant needed connectors to the same dozen systems, and every connector was written again for every product. Teams called this the N by M problem. With N applications and M systems, the industry was writing N times M integrations.

Adoption moved quickly through 2025. Other model providers, IDEs, coding agents and agent frameworks added MCP clients, and thousands of community servers appeared for databases, cloud platforms, developer tools and business software. The specification gained dated revisions that added a streaming HTTP transport, a standard authorization model based on OAuth, structured tool output, elicitation and long-running work.

In December 2025 MCP was placed under the Agentic AI Foundation, a Linux Foundation project that also holds other open agent standards. The A2A protocol for agent-to-agent communication joined the same foundation in 2026. Neutral governance matters for a protocol, because companies are more willing to build on a standard that no single vendor controls.

The revision dated 2026-07-28 made one of the largest changes so far. It removed the connection handshake and the session header from the base protocol, so each request carries what the server needs and servers can scale behind an ordinary load balancer. It also introduced a formal extensions framework, with tasks for long-running work as one of the first extensions.

How it works

The message layer

Every MCP exchange is a JSON-RPC 2.0 message: a request with an id, a method and parameters, a response with a result or an error, or a notification with no reply. Method names describe the operation, for example tools/list to discover tools, tools/call to run one, resources/read to fetch a resource and prompts/get to expand a prompt.

Discovery

Before a model can use a tool, the host asks the server what it offers. The server returns a list of tools, each with a name, a natural-language description and an input schema. The host passes these definitions to the model. The description is not decoration. It is the main signal the model uses to decide whether and how to call the tool, so it should say plainly what the tool does, when to use it and what it returns.

Servers can tell clients how long a tool list may be cached, and can notify clients when the list changes. A client that caches the list avoids a round trip on every turn.

Invocation

When the model decides to use a tool, it produces a structured call with the tool name and arguments that match the schema. The host checks the call, may ask the person to approve it, and sends tools/call to the server. The server runs the action and returns content: text, images, embedded resources, or structured output that matches a declared output schema. The host gives the result back to the model, which continues reasoning or answers the person.

Transports

MCP separates the message format from how messages travel.

stdio runs the server as a local child process and exchanges messages over standard input and output. It is simple and needs no network, which suits local tools such as a file system or a Git repository.
Streamable HTTP runs the server as a web service. The client sends requests with HTTP POST, and the server can answer with a single JSON response or stream several messages back. This is the transport for remote servers that many users share.

Since the 2026-07-28 revision the base protocol is stateless: there is no initialize handshake and no session id that ties a client to one server instance. A routing header carries the method name, so gateways can route and rate-limit without parsing bodies. In practice this means a remote MCP server can be run like any other stateless API, with horizontal scaling and no sticky sessions.

Authorization

Remote servers need to know who is calling and what that caller may do. MCP uses OAuth for this. The MCP server acts as a protected resource. It advertises which authorization server issues its tokens, and the client runs a standard OAuth flow, usually authorization code with PKCE, to obtain an access token for the person. The token is then sent with each request. Scopes limit what the token allows, and the server checks the token on every call.

This design keeps passwords out of the model and out of the client. The person signs in with the service that owns the data, and the service decides what the agent may reach.

Long-running work

Some tools take minutes or hours: a data export, a model training run, a large report. The tasks extension lets a tool call return a task handle at once. The client then polls or subscribes for progress and fetches the result when it is ready. This keeps the conversation responsive and avoids timeouts.

Key concepts and terms

Term	Meaning
Host	The AI application that owns the model and the conversation.
Client	The MCP connector inside the host, one per server.
Server	A program that exposes tools, resources and prompts over MCP.
Tool	A model-callable function with a name, description and input schema.
Resource	Read-only context identified by a URI and attached by the application.
Prompt	A reusable template that a person chooses to run.
Sampling	A server asking the host's model to generate text.
Elicitation	A server asking the person for input through the host.
Roots	Locations a server is allowed to work within.
stdio	Local transport over a child process's standard streams.
Streamable HTTP	Remote transport over HTTP, with optional streaming responses.
Task	A handle for long-running work that is polled or subscribed to.
Extension	An optional capability defined outside the core protocol.
Protected resource	An MCP server that requires an OAuth access token.

A worked example

Consider an operations team that wants its assistant to answer questions about orders and open support tickets. The data lives in a PostgreSQL database and a ticketing system.

The team writes one MCP server with three tools:

{
  "name": "find_orders",
  "description": "Find orders for a customer. Use when the user asks about a customer's purchases, deliveries or refunds. Returns at most 50 orders, newest first.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customer_email": {"type": "string", "format": "email"},
      "since": {"type": "string", "format": "date", "description": "Optional start date"}
    },
    "required": ["customer_email"]
  }
}

The other two tools are get_ticket and add_ticket_note. The first two only read. The third writes, so the host is configured to ask for approval before calling it.

The server also exposes a resource, schema://orders, that describes the order table, and a prompt, "Customer status summary", that the team uses every morning.

A support lead asks: "What happened with the order for ayse@example.com last week, and is there a ticket?"

The host already knows the server's tools from discovery. It passes them to the model with the question.
The model calls find_orders with the email and a date a week back.
The server queries the database with a read-only role and returns three orders as structured output.
The model sees that one order was refunded and calls get_ticket with the order id.
The server returns the ticket, which shows a delayed shipment and a promised callback.
The model answers in plain language and offers to add a note. The lead agrees, the host shows the exact note for approval, and only then is add_ticket_note called.

The same server works in the team's chat assistant, in a developer's IDE and in a scheduled agent that writes the morning summary, without any change.

Strengths and limitations

Strengths

Write once, use everywhere. A connector built as an MCP server works in every MCP client, which cuts integration cost sharply.
Clear roles. Tools, resources and prompts separate model actions, application context and user workflows.
Discovery at run time. Clients learn a server's abilities when they connect, so servers can add tools without client releases.
Standard security model. OAuth-based authorization lets organisations reuse their identity systems and scopes.
Local and remote. stdio suits local developer tools, and Streamable HTTP suits shared services.
Neutral governance. Foundation stewardship lowers the risk of building on a single vendor's format.

Limitations

Tool overload. Connecting many servers can give a model hundreds of tools. Long tool lists cost context and lower selection accuracy.
Security is the server's job. The protocol carries authorization, but a badly scoped server can still leak data or take harmful actions.
Prompt injection. Tool results can contain hostile instructions. MCP does not make untrusted text safe.
Quality varies. Community servers range from excellent to abandoned. Each one is code you run and trust.
A moving specification. Dated revisions have changed transports and session handling. Teams must track versions and test clients against servers.

How it compares with alternatives

Approach	What it is	When it fits better
Native function calling	Tools defined directly in one model provider's API request	A single application, one model, few tools, no reuse needed
Plugin formats tied to one product	Connectors that work only inside one assistant	Deep integration with one product's interface
Plain REST or GraphQL	Direct API calls written in application code	Fixed workflows where no model decides what to call
A2A	A protocol for agents delegating tasks to other agents	Cross-vendor agent collaboration, not tool access
OpenAPI-to-tool generators	Turning an existing API description into tool definitions	Quick exposure of an existing API, often wrapped as an MCP server

Function calling and MCP are complementary rather than rival. Function calling is how a model expresses that it wants a tool. MCP is how the host finds, describes and reaches that tool. A2A sits one level higher: MCP connects an agent to its tools, while A2A connects one agent to another agent.

Role in tabular foundation models

Tables sit at the centre of most business data, and tabular foundation models are built to read them directly. MCP is a natural way to put such a model in reach of an agent. A server can expose tools such as predict_column, impute_missing, detect_anomalies or match_tables. The agent decides when a question needs a model prediction rather than a SQL aggregate, gathers the right rows with a query tool, and hands them to the prediction tool as context.

Resources help here too. A server can publish a table's column profile, units and known data issues as resources, so the agent sees them before it calls anything. Long jobs such as building an endpoint over a large dataset fit the tasks extension. I describe one such server, including its tools and sign-in flow, in the MCP server documentation for the large tabular foundation model on this site.

Practical guidance and best practices

Design tools around tasks, not endpoints. One tool that answers "find a customer's recent orders" beats five thin wrappers over raw API routes. Fewer, clearer tools improve model accuracy.
Write descriptions for the model. State what the tool does, when to use it, what it returns, its limits and its side effects. Give argument descriptions and formats.
Return structured output. Declare an output schema and return compact, typed results. Avoid dumping whole API payloads into the context.
Separate read and write. Make read tools safe to call freely. Mark write tools clearly and require human approval in the host.
Scope access tightly. Use per-user OAuth tokens, minimal scopes and read-only database roles where possible. Never place shared admin keys in a server.
Treat tool results as untrusted. Content from web pages, emails or tickets can carry injected instructions. Keep it labelled as data, and do not let it change permissions.
Limit and paginate. Cap result sizes, support pagination and truncate long text with a clear marker.
Make errors useful. Return messages that tell the model what went wrong and what to try next, such as a missing field or an invalid date.
Log every call. Record who called which tool, with which arguments and what result, for audit and debugging.
Version and test. Pin the protocol revision you support, run contract tests against the clients you care about, and test tool selection with real questions.

Common mistakes

Exposing every API route as a tool. The model drowns in options and picks the wrong one.
Vague descriptions. "Gets data" tells the model nothing about when to use the tool.
Unbounded results. A tool that returns ten thousand rows fills the context and costs money.
Shared credentials. One service key for all users breaks auditing and least privilege.
Silent write actions. Writes without confirmation surprise people and cause real damage.
Trusting tool output. Following instructions found inside retrieved text is the classic injection path.
Ignoring revisions. Assuming the old session handshake after servers have moved to the stateless revision breaks connections.

Frequently asked questions

What is MCP in one sentence?

MCP is an open protocol that lets AI applications connect to tools, data and prompt templates through a common client and server interface, so one connector works across many AI products.

Who created MCP and who governs it now?

Anthropic introduced MCP in November 2024. Since December 2025 it has been stewarded by the Agentic AI Foundation, a Linux Foundation project, with changes proposed and reviewed in the open.

Is MCP the same as function calling?

No. Function calling is how a model asks to use a tool inside one provider's API. MCP is how an application discovers tools on external servers and calls them. A host usually uses both: MCP to find and reach tools, function calling to let the model choose them.

What is the difference between an MCP tool and a resource?

A tool is an action the model decides to take, such as running a query. A resource is read-only context that the application decides to attach, such as a file or a schema. Tools change or fetch things on request; resources are context.

Do I need to host an MCP server on the internet?

No. Local servers run as child processes over stdio and never touch the network. Remote servers over Streamable HTTP are needed only when many users or cloud agents must share the same server.

How does authentication work for remote MCP servers?

The server acts as an OAuth protected resource. The client runs an OAuth flow, usually authorization code with PKCE, gets an access token for the person, and sends it with each request. The server checks the token and its scopes on every call.

What changed in the 2026-07-28 revision?

It removed the initialize handshake and the session header from the base protocol, making servers stateless and easier to scale, added a header that lets gateways route by method, and introduced a formal extensions framework with tasks for long-running work.

Is MCP secure?

The protocol provides a sound authorization model, but safety depends on implementation. Scope tokens tightly, separate read and write tools, require approval for actions, log calls and treat tool output as untrusted input.

How many tools should one server expose?

As few as cover the real tasks. Many good servers expose between three and fifteen tools. If a client connects many servers, use tool filtering or search so the model sees only the relevant ones.

How does MCP relate to A2A?

They solve different problems. MCP connects an agent to tools and data. A2A connects an agent to other agents so they can delegate and track tasks. Both are stewarded by the Agentic AI Foundation, and many systems use both.

Glossary

Agent: a model-driven loop that chooses actions and observes results.
Agentic AI Foundation: the Linux Foundation project that stewards MCP and related agent standards.
Context window: the amount of text a model can read at once.
Elicitation: a server-initiated request for input from the person.
Gateway: a proxy that routes, authenticates and rate-limits MCP traffic.
JSON-RPC 2.0: a lightweight remote procedure call format based on JSON.
JSON Schema: a vocabulary for describing the shape of JSON data.
OAuth: an open standard for delegated authorization with access tokens.
PKCE: an OAuth extension that protects the authorization code flow.
Prompt injection: hostile instructions hidden in content a model reads.
Sampling: a server asking the host's model to generate text.
Scope: a permission attached to an access token.
Stateless: each request carries what is needed, with no server-side session.
Streamable HTTP: MCP's HTTP transport with optional streaming.

Summary

MCP gives AI applications one standard way to reach tools, data and prompts. Hosts run clients, clients talk to servers, and servers expose tools for the model, resources for the application and prompts for the person. Messages are JSON-RPC, transports are stdio for local use and Streamable HTTP for remote use, authorization runs on OAuth, and since the 2026-07-28 revision the base protocol is stateless with an extensions framework for features such as long-running tasks. The protocol removes most integration cost. Safety, tool design and scoping remain the job of the people who build and run servers.

It belongs to Protocols in my stack, under Agentic AI. Others in the same group:

A2A Function calling Structured outputs OAuth for tool access