MCP: The Open Standard
How the Model Context Protocol connects agents to external systems — servers, resources, tools — and when to use versus build one.
The N-by-M problem
Before MCP, every AI application that wanted to talk to every external system needed a custom integration. Ten AI apps times ten systems (GitHub, Slack, Postgres, Figma...) meant up to a hundred bespoke connectors, each with its own auth, its own bugs, its own maintenance bill.
The Model Context Protocol (MCP) is the open standard that collapses this to N + M: each AI app implements MCP once, each system exposes an MCP server once, and everything interoperates. Anthropic's tagline — "USB-C for AI" — is accurate: one port shape, any device. Released in late 2024, it became the de facto industry standard.
The architecture: hosts, clients, servers
Three roles, easy to confuse, worth getting exactly right:
- MCP host — the AI application the user runs: Claude Code, Claude Desktop, VS Code.
- MCP client — a connection object inside the host. The host creates one client per server it connects to.
- MCP server — the program exposing a system's capabilities: a Postgres server, a GitHub server, a Figma server.
Servers run in two ways:
| Transport | Where the server runs | How it connects |
|---|---|---|
| stdio | locally, as a child process of the host | pipes over standard input/output — no network, no auth needed |
| streamable HTTP | remotely, as a service | HTTP with OAuth for user authorization |
A local filesystem server uses stdio; your company's hosted Jira integration uses streamable HTTP with OAuth.
What a server exposes
Servers offer three primitives — categories of capability:
- Tools — executable functions the model decides to invoke ("run this query," "create this issue"). The workhorse primitive.
- Resources — contextual data the host can read: a database schema, a file, a document. Data, not actions.
- Prompts — reusable interaction templates a server ships, like a well-tested "summarize this table" prompt.
Clients expose primitives too. The one that matters today is elicitation — a server asking the user for input mid-operation ("which environment do you want to deploy to?"). Two older client primitives, sampling and logging, were deprecated in the 2026-07-28 protocol revision, which also made the protocol stateless and added server/discover — servers no longer need to hold session state between calls.
The wire format
Under the hood, MCP is JSON-RPC 2.0 — a simple request/response format in JSON. The method names follow a pattern you can guess:
- Discovery:
tools/list,resources/list,prompts/list— "what do you offer?" - Retrieval:
resources/get,prompts/get— "give me that item." - Execution:
tools/call— "run this tool with these arguments." - Notifications: opt-in subscriptions (
subscriptions/listen) so a server can announce that its tool list changed.
The discovery step is what makes MCP more than a plugin registry: an agent can connect to a server it has never seen and ask what's available.
Using MCP in practice
In Claude Code, connecting a server is one command:
claude mcp add postgres-db -- npx @example/postgres-mcp "postgresql://localhost/mydb"
After that, asking "which customers churned last month?" works end to end: Claude discovers the schema resource, sees the query tool, writes SQL, and calls tools/call — zero bespoke integration code. The same pattern connects issue trackers, monitoring dashboards, and design tools.
Two practical rules keep MCP usage efficient:
1. Prefer a CLI when a good one exists. Tools like gh, aws, and sentry-cli are the most context-efficient integration of all — the agent already knows them, they cost zero tool-definition tokens, and they're battle-tested. Reach for an MCP server when there's no CLI, when you need structured discovery, or when OAuth-guarded remote access matters.
2. Use progressive tool discovery for large servers. A server exposing 200 tools would burn thousands of context tokens if every definition loaded upfront. Instead, load definitions on demand as the agent needs them — the same "don't front-load everything" principle that governs all context engineering.
Use one, or build one?
Use an existing server when your target is a mainstream system — GitHub, Slack, Postgres, Google Drive, Figma all have maintained servers. This is the whole point of a standard: someone already did the work.
Build your own when:
- the system is internal (your company's order database, your deploy pipeline),
- existing servers expose the wrong granularity — raw API endpoints when your agent needs workflow-shaped operations,
- you need tight control over auth, filtering, or what data can leave the system.
Building one is smaller than it sounds: official SDKs handle the protocol, so your job reduces to writing the tool functions and descriptions — which is exactly the skill the next lesson teaches. The protocol gets your tools to the agent; whether the agent can use them well is a design problem the standard cannot solve for you.