The USB-C analogy
Before USB-C, every device had its own cable: micro-USB, Lightning, mini-DIN, weird proprietary plugs. To support all of them you bought a drawer of adapters and crossed your fingers.
MCP — Model Context Protocol is USB-C for AI. One standard wire format. Build a server that exposes your database, your design tool, your CRM — any MCP-aware client (Claude Code, Cursor, IDEs, agents) plugs in instantly. No bespoke per-client integration code.
What MCP standardises
A wire format for three things every agent needs:
- Tools — things the agent can do (run a query, send a message, read a file).
- Resources — context the agent can read (a doc, a row, a screenshot).
- Prompts — reusable prompt templates the server exposes.
Everything else (transport, auth, streaming) is layered on top of that core.
How an MCP session looks
- Initialize — client and server agree on protocol version and capabilities.
- List tools / resources / prompts — server tells client what it offers.
- Call — client invokes a tool with arguments, gets a structured result back.
- Notify — server can stream updates or push changes (resource updated, tool list changed).
That is the entire wire conversation. Six-ish message types in total. Small surface, big leverage.
Why this matters
Without MCP, every "Claude can talk to GitHub" or "Cursor can use Postgres" is bespoke. With MCP:
- One GitHub MCP server works in Claude Code, Cursor, custom SDK agents — anywhere MCP is supported.
- One company-internal MCP server wraps your APIs once; every agent in the org uses it.
- The same server can be used by non-Anthropic clients — MCP is open and not Claude-specific.
Two transports you'll see
- stdio — the server runs as a child process; messages go over
stdin/stdout(newline-delimited JSON). Lowest latency, easy local dev. - HTTP / streamable HTTP — server is a long-lived web service; multiple clients can connect. Better for shared / cloud servers.
You pick one based on deployment shape, not protocol expressiveness — both speak the same MCP.
Building an MCP server
Skeleton in any language: declare a list of tools, write the handler for each, expose over stdio or HTTP. SDKs in TypeScript, Python, and others wrap the boilerplate. Most useful servers are 100–500 lines.
When to build vs use
Use existing servers when one fits — Postgres, GitHub, Filesystem, Puppeteer/browser, Notion, etc. Build your own when you wrap internal systems: company APIs, internal data stores, custom tooling. Building is mostly bookkeeping; the AI value is in exposing the right primitives.
Common confusions
- MCP is not a model — it's a protocol. The model lives in the client; the tools live in the server.
- MCP is not a vector DB or a memory layer — those can be exposed via MCP, but MCP itself is just the wire.
- MCP does not authenticate — auth is at the transport layer (HTTP headers, OS-level permissions for stdio). Build accordingly.
In one line
MCP is the smallest standard that turns "build N integrations for M agents" into "build N servers, get every M for free."