The Model Context Protocol (MCP) is an open standard, released by Anthropic in November 2024, for connecting AI applications to external tools, data, and systems. Instead of every AI app writing custom integration code for every data source, MCP gives both sides a shared protocol: a system exposes its capabilities once as an MCP server, and any MCP-compatible AI application can use them through a generic client.
The problem it solves
Before MCP, connecting an LLM-based application to, say, a Postgres database, a Git host, and a ticketing system meant hand-writing bespoke function-calling glue for each pairing. Do that across several AI applications and several systems, and integration effort grows as M×N — M applications times N systems, each combination built separately.
MCP turns this into an M+N problem. A system builds one MCP server. Every MCP-aware host — a chat client, an IDE assistant, an autonomous agent runtime — can talk to it without writing integration-specific code. It's the same shape of problem the Language Server Protocol solved for editors and language tooling: one protocol, many implementations on each side.
The three roles
MCP defines a small cast of participants:
- Host — the AI application the user actually interacts with (a chat client, an IDE, an agent framework).
- Client — lives inside the host and keeps a 1:1 connection to a single server.
- Server — a process, local or remote, that exposes capabilities over MCP, typically wrapping an existing API, database, or filesystem.
A host can hold connections to many servers at once — one for your codebase, one for a ticket tracker, one for internal docs — and present all their capabilities to the model as a single, merged toolset.
What a server exposes
Servers advertise up to three kinds of capability:
- Tools — named, callable functions with a JSON Schema for their inputs (and, in current spec versions, an optional schema for structured output). This is what lets a model take action: query a database, create a ticket, run a build.
- Resources — addressable, read-only data (files, rows, API responses) the host can pull into context.
- Prompts — reusable, parameterized prompt templates a server can offer to a host.
Tools are the most commonly used capability and the one most directly tied to reliability, since a model decides which tool to call and how to fill its arguments based on the tool's name, description, and schema, not on human review of that individual call.
Transports
MCP is transport-agnostic. Two transports dominate in practice:
- stdio — the server runs as a local subprocess and communicates over standard input/output. Common for local tools and IDE integrations.
- Streamable HTTP — the server runs remotely and communicates over HTTP, allowing multiple clients and centralized hosting. This has replaced the older HTTP+SSE transport, which is now deprecated.
Underneath both transports, messages are JSON-RPC 2.0: requests, responses, and notifications with a consistent envelope.
How a session works, briefly
A client connects to a server, negotiates a shared protocol version and capability set, then calls methods like tools/list to discover what's available and tools/call to invoke a specific tool. (We cover the discovery handshake itself in detail in a companion article.)
Where the spec is heading
MCP has moved fast: the 2025-03-26 and 2025-06-18 revisions added structured tool outputs and OAuth-based authorization; 2025-11-25 added further protocol refinements. The newly finalized 2026-07-28 revision is a bigger shift — it removes MCP's session-based handshake in favor of a stateless, per-request model, aimed at making remote servers easier to run behind ordinary load balancers. Adoption of that revision will take time; the large majority of servers running today still speak the session-based protocol described above, and new clients are expected to fall back to it automatically.
Why reliability is the open question
MCP standardizes the shape of the conversation between a model and a tool, but it doesn't guarantee that shape stays constant. Servers get redeployed, schemas change, descriptions get edited to shift model behavior — and because the model, not a human, is the one reading the tool list and deciding how to call things, small changes on the server side can quietly break agents that depend on it. That's the gap tools like MCP Vitals are built for: running the actual MCP handshake against your servers on a schedule, diffing tool schemas over time, and alerting before a silent change turns into a broken agent in production.
Getting started
If you're building an MCP server, start with the official SDKs (TypeScript, Python, and others are maintained under the modelcontextprotocol GitHub organization) and the reference documentation at modelcontextprotocol.io. If you're running one in production, treat it like any other service boundary: monitor it, version your tool schemas deliberately, and watch for drift before your users, or their agents, do.