Model Context Protocol
What MCP is, who introduced it, how it actually works, and the problem it solves. Plus a stack of reference links so you can go straight to the source.
What MCP Is
Model Context Protocol (MCP) is an open standard that lets AI assistants connect to data sources and tools through a uniform protocol. Think of it as USB for AI integrations, one cable shape, plug in anything that speaks it.
An MCP client (Claude Desktop, Claude Code, Codex, Gemini CLI, Cursor, Continue, and a growing list of others) talks to an MCP server (a small process that exposes some real-world capability) over JSON-RPC. The server tells the client what it can do, the client surfaces those capabilities to the AI model, and the model decides when to call them. The transport is either stdio (for local servers spawned as child processes) or HTTP with server-sent events (for remote servers behind an URL).
The protocol is small on purpose. Three primitives, three transports, one JSON-RPC dialect. Everything else, including the servers in this directory, is an application of those pieces.
Where It Came From
MCP was introduced by Anthropic in November 2024. The motivation was straightforward, the team kept hitting the same wall: every time you wanted an LLM to read a new system, you wrote a new bespoke integration. N AI apps multiplied by M tools is a lot of glue code, and none of it was reusable across vendors.
The fix was to standardize the wire format. If clients and servers agree on a protocol, anyone can write a server for their system once and have it work across every compliant assistant. Anthropic open-sourced the spec, the reference SDKs (TypeScript, Python, Java, Kotlin, Rust, Swift, and more), and a set of example servers from day one. Within a year it picked up support from major IDE and assistant vendors, including OpenAI's Codex, Google's Gemini CLI, Cursor, Zed, Continue, and Docker's MCP Gateway / Toolkit, all of which speak the same protocol Claude Desktop does.
MCP is governed in the open through the modelcontextprotocol GitHub organization. The spec evolves through versioned protocol revisions; servers and clients negotiate the version they share at connection time.
How It Works
There are three roles in any MCP session:
| Role | What it is | Example |
|---|---|---|
host |
The AI app the user is in. It owns the conversation and the LLM. | Claude Desktop, Claude Code, Cursor, Codex, Gemini CLI. |
client |
One connection from the host to one MCP server. The host spawns or opens one client per server it wants to use. | Internal to the host. You don't usually configure it directly. |
server |
A process that exposes capabilities (tools, resources, prompts) over MCP. Knows nothing about the model, only about the data or system behind it. | The servers in this directory. PAN-OS, Meraki, ISE, UniFi, etc. |
A server can expose three kinds of capabilities:
| Capability | What the model gets | Used for |
|---|---|---|
tools |
Callable functions with typed JSON-schema inputs. | Querying APIs, running commands, anything the model should be able to trigger. |
resources |
Read-only data the model can pull on demand (files, records, configs). | Giving the model context it can choose to read. |
prompts |
Pre-templated prompts the user (or the model) can invoke. | Repeatable workflows, like a canned "summarize this audit log" prompt. |
And two main transports:
| Transport | How the client reaches the server | When to use it |
|---|---|---|
stdio |
Host launches the server as a child process; JSON-RPC over stdin/stdout. | Local servers. Every server in this directory uses stdio. |
HTTP / SSE |
Host opens an HTTP connection; JSON-RPC over server-sent events (and the newer Streamable HTTP). | Remote servers, SaaS-hosted servers, anything not running on the same machine. |
The handshake is small: the client sends initialize with its
capabilities and protocol version, the server responds with its own. From there
the client calls tools/list, resources/list, and
prompts/list to discover what's available, then invokes a tool via
tools/call when the model decides to. The host stays in control of
user consent: by default it asks before letting the model call a tool, and the
tool catalog is visible to the user before the conversation starts.
What It Solves For
Before MCP, plugging an LLM into a real system meant writing custom integration code on both sides. Every assistant had its own plugin format, every plugin had to be rewritten when a new assistant arrived, and credentials, tool catalogs, and trust boundaries were ad-hoc per integration. The N × M scaling problem was real, and most teams gave up after one or two integrations.
After MCP, both sides agree on the wire format. Write a server once and every MCP-capable client can use it. Build a client with MCP support and it inherits the whole ecosystem of existing servers. The directory on this site is one expression of that, the same server runs against Claude Desktop, Claude Code, Codex, Gemini CLI, and any other compliant client without code changes.
What you get in practice:
- Standardization. One protocol, many integrations. Server code is portable across clients.
- Scoped credentials. Each server holds its own secrets in its own process, scoped to its host. The host never sees the credential, only the tool catalog.
- Explicit consent. The host enforces user consent before tool calls. The model can want to call something; only the user can let it.
- Modularity. Swap a server, swap an integration. No host rewrites.
- Open ecosystem. Not vendor-locked. The spec, SDKs, and tooling are open source under the modelcontextprotocol GitHub org.
Reference Links
Straight from the source. All maintained by Anthropic or the open MCP working group.
- modelcontextprotocol.io, the canonical home of the protocol. Docs, concepts, examples, client list.
- Anthropic's announcement post (Nov 2024), the original "why we built this" introduction.
- The MCP specification, the protocol document itself. Versioned, JSON-RPC, ground-truth for what the messages look like.
- List of MCP clients, which hosts speak the protocol today. Useful before picking a client to standardize on.
- github.com/modelcontextprotocol, the official GitHub organization. Reference SDKs (Python, TypeScript, Java, Kotlin, Rust, Swift, C#), example servers, the inspector, the spec source.
- Anthropic's documentation, broader Claude docs, including how to build MCP-aware agents and how Claude Desktop and Claude Code wire MCP into the assistant.