Model Context Protocol (MCP) for AI Agents

The problem MCP addresses

An agent becomes useful when it can reach things outside the model, such as files, tickets, databases and APIs. Without a shared standard, each application writes its own integration for each system. Those integrations cannot easily be reused by another application, even when they do the same job.

MCP separates the two sides. A team can wrap a system in an MCP server once, and any application with MCP client support can connect to it. The official documentation is careful about the scope: MCP covers the exchange of context, and it does not dictate how an application uses its language model or manages what it receives.

The protocol is under active development, and details have changed between versions. This guide is based on the documentation and the specification version dated 2026-07-28, which was the latest available when it was written. Older tutorials may show a different connection sequence, so check the version your SDK and clients support.

Hosts, clients and servers

The official architecture overview names three participants:

Host. The AI application that coordinates everything, such as an assistant or a code editor.
Client. A component inside the host that maintains a connection to one server. A host creates one client for each server it connects to.
Server. A program that provides context and capabilities. The word describes its role, not where it runs, so a server can be local or remote.

Note that the model is not a participant in the protocol. The model never connects to a server directly. It asks the host's application code for a tool call through whatever mechanism the model provider offers, and the application routes that request through MCP. This gives your application a natural place to apply checks.

What a server can offer

MCP defines three core primitives that servers can expose:

Primitive	What it is	Example
Tools	Executable functions the AI application can invoke	Run a query or call an API
Resources	Data sources that provide context	A file's contents or a database schema
Prompts	Reusable templates for structuring interactions	A template with a few worked examples

Clients can offer features to servers too. Elicitation lets a server ask the user for more information or for confirmation. Sampling, which allowed a server to request a model completion through the client, is marked as deprecated in the 2026-07-28 version, so avoid relying on it in new work. Tools are the primitive most relevant to agents, and they are also where most of the risk lies.

How an agent uses MCP

A typical interaction has four stages:

Connect. The host connects to each configured server. A client can learn a server's capabilities and supported protocol versions through a server/discover request. Older protocol versions used an initialisation handshake instead, which is one reason to check versions.
List. The client calls tools/list and receives each tool's name, description and JSON Schema for its input. The application can combine the tools from every server into one registry for the model.
Decide. The model sees those tool definitions alongside the conversation, and may ask for one to be called with particular arguments.
Call. The application routes the request to the correct server with tools/call, then returns the result to the model, which continues working.

The messages use JSON-RPC 2.0. This simplified, illustrative request shows the core of a tool call. The tool name and arguments are invented, and the per-request metadata required by the specification has been left out for readability:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "search_tickets",
    "arguments": { "query": "login error", "limit": 5 }
  }
}

In practice, an SDK normally handles this format for you. You still own what happens around it, including the agent loop, step limits, and the decision about whether a given call should go ahead. Good tool design matters as much as it does without MCP, so the advice in tool calling for AI agents applies directly: clear descriptions, tight schemas and errors the model can act on.

Local and remote servers

The specification defines two standard transports:

stdio. The client launches the server as a local subprocess and they exchange messages through standard input and output. On this transport, a stray print statement to standard output can corrupt the message stream, so logs must go elsewhere.
Streamable HTTP. The server runs independently and can serve many clients over HTTP, optionally streaming with Server-Sent Events. Older material may mention a separate HTTP and SSE transport, which this replaced.

As a rule of thumb, stdio suits a tool that runs alongside one user's application, and HTTP suits a shared service. A remote server also needs authentication and the usual operational care. The documentation recommends OAuth for obtaining tokens, and warns local HTTP servers to validate the Origin header and bind only to localhost.

A small server

The following sample is illustrative. It follows the shape of the official Python quickstart at the time of writing, and the SDK's class names have changed over time, so check the current documentation before you use it. The ticket lookup is a placeholder:

# Illustrative only. search_ticket_store is a placeholder.
from mcp.server import MCPServer

mcp = MCPServer("tickets")

@mcp.tool()
def search_tickets(query: str, limit: int = 5) -> list[dict]:
    """Search support tickets by keyword. Read-only."""
    return search_ticket_store(query, limit=min(limit, 20))

if __name__ == "__main__":
    mcp.run(transport="stdio")

The type hints and docstring generate the tool definition, which means the docstring is effectively a prompt read by the model. Notice also that the code caps the limit itself, without relying on the model to behave.

Security decisions you still own

A standard connection does not make a tool safe. The specification states plainly that MCP cannot enforce its security principles at the protocol level, and leaves them to implementers. It treats tools as arbitrary code execution, and says that hosts must obtain explicit user consent before invoking any tool. The main concerns are:

Untrusted servers. A server is code or a service you are choosing to rely on. Tool descriptions and annotations should be considered untrusted unless they come from a trusted server, because a description reaches the model and can influence its behaviour.
Injection through results. A ticket, web page or file returned by a tool may contain instructions. If the same agent has both untrusted input and powerful tools, the risk is significant. See LLM guardrails and prompt injection defence.
Excess permissions. Give each server only the access it needs, and prefer read-only access or per-user credentials over a broad shared token.
Consequential actions. Sending, paying or deleting should pass through a checkpoint outside the model, as described in human-in-the-loop approval for AI agents.
Changing definitions. A server's tool list can change over time. Consider reviewing what is exposed, and pin versions of the servers you install where possible.

Connecting many servers has a practical cost too. Every tool definition sent to the model uses context, and a long list of similar tools makes choosing harder. Expose only what a given agent needs. The official material also discusses discovering tools progressively for clients that use many servers.

Testing an MCP integration

Test at two levels. First, exercise the server without a model, calling each tool with valid and invalid input, and confirm that its errors are useful. The official tooling includes an inspector for developing servers. Then test the agent with realistic requests, and check that it selects the right tool and passes sensible arguments.

When MCP is worth using

MCP pays off when integrations need to be shared: several applications or teams using the same tools, or an existing client you want to extend, such as an assistant or an editor that already speaks the protocol. It also helps to have one clear boundary between an agent and the systems behind it.

It may be unnecessary when one application calls one or two of its own functions. A direct in-process tool call has fewer moving parts, and you can add a server later if reuse becomes a real requirement. Whichever you pick, the difficult questions remain the same, including which agent gets which tool and whether you need several agents at all.

If you are designing agents that need controlled access to tools and data, the multi-agent systems page describes what I can help with.

Frequently asked questions

What is MCP in simple terms?

MCP, the Model Context Protocol, is an open protocol for connecting AI applications to external tools and data. A server exposes capabilities in a standard format, and any compatible client application can discover and use them.

Is MCP the same as tool calling?

No. Tool calling is how a model asks for a function to run. MCP standardises how an application discovers and reaches tools provided by a server. The two work together, and a model need not know that MCP is involved.

Do I need MCP to build an AI agent?

No. An agent can call functions defined directly in your application. MCP becomes more useful when several applications share the same integrations or when you want to connect to an existing MCP-compatible client or server.

Is MCP secure?

Not automatically. The specification sets out consent and safety principles, but says it cannot enforce them at the protocol level. You must vet servers, limit permissions, treat tool output as untrusted and require approval for consequential actions.

Model Context Protocol: what it is and how agents use it