The Model Context Protocol (MCP) is an open protocol introduced by Anthropic on November 25, 2024 that standardizes how LLM applications connect to external tools and data. It answers not "how does the agent decide what to call" but "how do any application and any source agree through a single contract."
Without a standard, each of M applications integrates with each of N sources its own way — at worst, M×N separate connectors. MCP turns M×N into M+N: an application becomes a client once, a source becomes a server once, and they stay compatible. The idea is often called "USB-C for AI applications" and "LSP for context."
At its core is a host ↔ MCP client ↔ MCP server architecture over JSON-RPC 2.0 with stdio and Streamable HTTP transports. A server exposes three primitives: tools, resources, prompts. The standard's main cost is trust in servers: a connected MCP server is an executable dependency with access to the model's context and a channel for prompt injection.
Practical value of this chapter
The M×N problem and why a standard
With M applications and N sources, a standard-free world needs M×N connectors. MCP makes an application a client and a source a server once — the USB-C and Language Server Protocol analogy ("LSP for context").
Three server primitives
tools (tools/list, tools/call) are picked by the model; resources (resources/list, resources/read) are injected by the app; prompts (prompts/list, prompts/get) are invoked by the user. The difference is who controls each primitive.
Transport and handshake
JSON-RPC 2.0 over stdio or Streamable HTTP (HTTP POST + SSE). A session begins with initialize and capability negotiation, then discovery and operation; the session stays stateful.
Security and operations
An MCP server is an executable dependency with context access: risk of prompt injection via tool descriptions and resources. You need an allow-list, sandboxing, OAuth for remote servers, and logging of every call.
Related chapter
Agentic Workflows & Tool Calling
MCP standardizes not the think-act loop itself, but how tools and data are connected to it.
The neighboring chapter on agentic workflows and tool calling covers how an LLM agent plans actions and reaches for tools, and the broader AI Engineering overview frames the whole discipline. This chapter is about something else: the Model Context Protocol (MCP) as an open protocol that standardizes how a model connects to tools and data. Not “how the agent decides what to call,” but “how any application and any source agree with each other through a single contract.”
The M×N problem: why a standard was needed
Without a standard, every AI application integrates with every tool in its own way. With M applications and N data sources, in the worst case you have to write and maintain M×N separate integrations: your own connector to GitHub, your own to Postgres, your own to Slack — and again from scratch in every application. Each new source requires its own implementation, and connected systems scale poorly.
The point of a standard is to turn M×N into M+N: an application learns to be an MCP client once, a source becomes an MCP server once, and from then on they are compatible with no bespoke integration. It is the same logic as USB-C (one connector for many devices) and the Language Server Protocol (one protocol instead of per-language support in every editor). MCP is often called “USB-C for AI applications” or “LSP for context.”
What MCP is: host ↔ client ↔ server
MCP is an open protocol introduced by Anthropic on November 25, 2024. At its core is a client-host-server architecture: a single host process manages multiple isolated clients, each holding a dedicated connection to its own server.
The host manages clients and enforces security policy; each client holds a one-to-one connection to its server. Servers are independent and isolated: each sees only the slice of context it needs, while the full conversation history stays in the host.
Server primitives: tools, resources, prompts
A server exposes three kinds of primitives. The real distinction is not purpose but who holds control, and that is where the trust boundary falls: the model picks tools, the application injects resources, the user invokes prompts.
Tools
Model-controlled
tools/list · tools/call
Callable functions with side effects: hit an API, mutate a record, kick off a job. The model picks a tool from its description and input JSON schema, but the spec requires keeping a human in the loop able to deny a call.
Resources
Application-controlled
resources/list · resources/read
Read-only data — files, database schemas, documents — addressed by URI. This is context for the model; how it gets injected (picker, search, auto-attach) is decided by the host application.
Prompts
User-controlled
prompts/list · prompts/get
Reusable interaction templates with parameters that the user typically invokes explicitly (for example, via a slash command). The server returns an expanded sequence of role-tagged messages with embedded content.
Transport and protocol
The message format is the same on top of any transport — only the boundary it crosses changes. The spec defines two standard transports (stdio and Streamable HTTP, with custom ones possible), and the client and server negotiate which one is used.
stdio
The server runs as a local process and exchanges newline-delimited JSON-RPC over stdin/stdout. Minimal latency and a simple trust model — a good fit for local integrations (files, git, local utilities).
Streamable HTTP
A remote server accepts HTTP POST and can stream responses via Server-Sent Events (SSE). This is the path for networked, multi-user, and cloud servers, where authentication and network boundaries appear.
JSON-RPC 2.0
One message format: request (with an id and a response), response, and notification (fire-and-forget, no id). The same wire format as the Language Server Protocol — hence the “LSP for context” analogy.
Session lifecycle: initialization and capability negotiation
- initialize. The client opens a session, declares its protocol version and capabilities, and receives the server's capabilities in return. No working calls run until the handshake completes.
- Capability negotiation. Both sides explicitly declare what they support: whether the server can serve tools/resources/prompts and change subscriptions, and whether the client can handle sampling. This lets the protocol extend without breaking compatibility.
- Discovery. The client requests tools/list, resources/list, prompts/list and passes their descriptions and schemas into the model's context.
- Operation. The model picks a tool, the client sends tools/call, resources are read by URI, and prompts are expanded. The session stays stateful until it is closed.
What MCP changes versus ad-hoc function calling
Without MCP, tool integrations are baked into the application: you describe functions directly in the agent's code and maintain them alongside it. That works, but it is not portable — another agent cannot reuse your connector, and you cannot plug in someone else's without rewriting it.
MCP decouples integrations from the application. A server becomes a standalone, reusable artifact: written once, it works with any MCP-compatible host. An ecosystem of ready-made servers emerges, and tool calling turns from a private application detail into a shared contract. The mechanism by which the model selects a tool stays the same — MCP standardizes connection and discovery, not the agent's reasoning process itself.
Security: trust, permissions, injection, isolation
Trusting the server
An MCP server sees requests and can return any text into the model's context. A third-party server from a public registry is an executable dependency with data access, not just a config entry.
Consent and permissions
The spec insists on explicit user consent: the host must disclose which data and tools are in play and keep a human in the loop to confirm calls with side effects.
Prompt injection via tools
A tool's description, parameter names, and resource contents flow into the model's context and can carry hidden instruction injection. A compromised or malicious server can steer the agent's behavior.
Isolation and sandboxing
The host isolates clients from each other: a server receives only the slice of context it needs, not the full conversation history. Local servers should run in a sandbox with restricted filesystem and network rights.
Operations: where to run, how to authenticate, how to observe
Where to run them
The transport choice immediately sets the operational burden. stdio servers live next to the host application as child processes and demand almost nothing; remote Streamable HTTP servers are full network services with their own scaling, timeouts, and overload handling.
Authentication
Remote servers need real authorization: the MCP spec describes an HTTP layer based on OAuth 2.1. Local stdio more often relies on process trust and passed-in environment variables.
Call observability
Every tools/call should be logged with arguments, result, and which server served it. Without observability you can neither debug the agent nor run a security audit.
Key trade-offs
- Standard versus ad-hoc: a shared protocol yields reusable servers and an ecosystem, but adds a layer of handshake, capability negotiation, and versioning on top of plain tool calling.
- Decoupling integrations from the application eases reuse, but shifts part of the responsibility (and risk) onto external servers you do not control.
- Remote servers give multi-user access and centralized updates, but bring network latency, authentication, and the operations of a full service.
- The more tools you connect, the wider the attack surface and the higher the chance the model picks the wrong tool or gets confused by similar descriptions.
Common mistakes
Recommendations
References
The chapter is pinned to MCP specification version 2025-06-18. For future releases, re-check session lifecycle, transport, server primitives, and security wording against the versioned docs.
Related chapters
- Agentic Workflows & Tool-Calling Architecture - How an agent plans and calls tools — the layer MCP standardizes from the source-connection side.
- AI Engineering: Overview - Context for the whole discipline: where tool and data integration sits in the AI application lifecycle.
- LLM Guardrails & Prompt Injection Safety - Why untrusted context from tools and resources is the main risk class when connecting external servers.
- GenAI RAG System Architecture - An alternative way to give a model context; MCP resources and RAG solve a nearby problem from different angles.