Model Context Protocol (MCP): The Complete Guide

What Is MCP?

MCP is an open standard that defines a common interface between AI applications and the tools or data they need. It uses JSON-RPC 2.0 for messaging, and it specifies how a client and server negotiate capabilities, list what is available, and invoke it.

The practical consequence is decoupling. Before MCP, connecting an AI assistant to Postgres meant writing assistant-specific code. With MCP, someone writes one Postgres server, and every compliant assistant can use it. The protocol is maintained in the open at modelcontextprotocol.io, with the specification and reference implementations on GitHub.

Governance has since moved beyond a single vendor. In December 2025 Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI, with Google, Microsoft, AWS, and Cloudflare among the backers. That matters practically: it is the difference between building on a competitor's API and building on a standard.

Why MCP Exists

The problem MCP solves is combinatorial. Connecting M AI models to N tools without a shared standard requires roughly M × N integrations, because every model-tool pair needs its own adapter. Each one is separately written, separately tested, and separately broken when either side changes.

A shared protocol collapses that to M + N. Each model implements the protocol once; each tool exposes one server. We break this arithmetic down in detail, along with when a plain REST endpoint is still the better answer, in MCP vs API.

This is worth stating plainly because it is often misread: MCP does not replace your API. It sits above it. The overwhelming majority of MCP servers in the wild are thin translation layers over a REST or GraphQL backend that already existed.

Architecture: Hosts, Clients, and Servers

MCP defines three roles, and the distinction between the first two trips people up:

• Host — the AI application the user actually interacts with: an IDE, a desktop chat app, a coding agent. The host manages the model, the conversation, and the user's permissions.
• Client — a connector living inside the host that maintains exactly one stateful connection to one server. A host running five servers instantiates five clients. This one-to-one pairing is what keeps server contexts isolated from one another. Our guide to MCP clients covers the lifecycle and capability negotiation in depth.
• Server — the process exposing capabilities. It might run locally as a subprocess or remotely behind HTTP, and it typically wraps an existing system.

The isolation property matters for security: because each client holds its own connection, a compromised or malicious server cannot directly observe traffic to other servers. It can still attack the model through what it returns, which is the subject of the security section below.

The Primitives: Tools, Resources, and Prompts

Servers can expose three kinds of capability, and choosing correctly matters:

• Tools are executable functions the model chooses to call — create_issue, run_query. They are model-controlled and can have side effects.
• Resources are read-only data identified by URI that the host loads as context — a file, a schema, a document. They are application-controlled, so the host decides what gets included rather than the model.
• Prompts are reusable templates the user explicitly invokes, typically surfacing as slash commands or menu items. They are user-controlled.

The control distinction — model, application, user — is the design guidance. If the model should decide when to fetch it, it is a tool. If the app should always supply it, it is a resource. If the human should trigger it, it is a prompt.

Clients can expose capabilities back to servers as well, including sampling (letting a server request a model completion), roots (telling a server which directories it may touch), and elicitation (letting a server ask the user for input mid-operation).

Transports: Local and Remote

MCP is transport-agnostic, but two options dominate. stdio runs the server as a local subprocess communicating over standard input and output. It is the simplest option, has no network surface, and suits developer tooling on a single machine.

Streamable HTTP is the remote transport, letting a server run as a networked service that multiple users can share. It superseded the earlier HTTP+SSE design and is what you use for anything hosted. Choosing between them, and the deployment options for each, is covered in how to host an MCP server.

The Server Ecosystem

The ecosystem grew from a handful of Anthropic reference servers to thousands of community and vendor implementations. Rather than list them here, we maintain a categorized directory of MCP servers covering developer tooling, databases, and cloud infrastructure.

The integrations most teams reach for first:

• GitHub MCP servers — repository access, issue triage, pull request review, and CI monitoring, via the official server or community alternatives.
• Claude MCP setup — configuring servers for Claude Desktop and Claude Code, plus the servers worth installing first.
• AWS MCP servers — the official AWS server suite and how they connect to agent runtimes.
• Bedrock AgentCore — AWS's managed runtime, including its gateway for turning existing APIs into MCP endpoints.

Building Your Own Server

Writing a server is more approachable than most people expect: the official SDKs handle protocol mechanics, so you define your tools and their schemas and let the SDK deal with transport and negotiation. A minimal useful server is well under a hundred lines.

The two halves of the job are covered separately. Our MCP server tutorial walks through implementation, schema design, and testing. Then hosting an MCP server compares the deployment paths, from local stdio through serverless and containers.

Running MCP in Production

Everything above describes one user and a handful of servers. Production introduces problems the protocol deliberately leaves open: who is allowed to call which tool, how credentials are issued and rotated, what gets logged, and how you stop one team's experiment from reaching another team's data.

The standard answer is to put a MCP gateway in front of your servers — a control point that handles authentication, allow-listing, rate limiting, and audit logging centrally rather than reimplementing it per server.

Once several servers are in play, the harder question becomes orchestration: which tools an agent should see for a given task, and how to keep tool counts from overwhelming the model's context. We cover those patterns in advanced MCP orchestration.

Security: What the Protocol Does Not Give You

MCP specifies message format and transport. It does not specify an authorization policy, and assuming otherwise is the root of most MCP security incidents.

The threats that matter in practice:

• Indirect prompt injection. Tool descriptions and returned data both enter the model's context. A malicious server — or a legitimate server returning attacker-controlled content — can carry instructions the model may act on.
• Over-scoped credentials. Servers are frequently handed a token far broader than the task requires, so a single compromise exposes everything that token can reach.
• Unvetted third-party servers. Installing a community server means running someone else's code with your credentials.

Our MCP security guide covers these with a deployment checklist, and AI agent security sets them in the broader context of agents that act autonomously. For the defensive side — using agents to run security operations rather than securing them — see agentic AI for cybersecurity.

Where MCP Fits in an Agent Stack

MCP is the integration layer, and only that. It says nothing about how an agent plans, what it remembers between sessions, or how you evaluate whether it did the job. Those belong to the surrounding stack described in AI agent infrastructure.

If you are building agents rather than integrations, MCP is one component alongside a framework and a runtime — see how to build AI agents and agentic AI frameworks. And if you would rather assemble something without writing code, many no-code agent builders now consume MCP servers directly.

Frequently Asked Questions