What Is MCP (Model Context Protocol)? The USB-C of AI Tools

// In plain English

MCP (Model Context Protocol) is an open standard for plugging tools and data sources into AI apps. It defines one common way for an assistant like Claude or a code editor like Cursor to discover what an external system can do, ask it to do something, and read data back — without anyone writing a custom integration for each pairing.

The official analogy is USB-C. Before USB-C, every phone and laptop had its own charger and its own cable. You needed a drawer full of adapters. USB-C is one port and one cable that works across devices. MCP is that idea for AI: one protocol so any AI app can plug into any tool, instead of every app inventing its own connector for every service.

An MCP server is the little program that wraps a system — your files, a database, GitHub, Slack, a weather API — and exposes it over MCP. The MCP host is the AI app (the chat client, the IDE, the agent). The host talks to the server and, through it, the model can read your calendar, query your database, or open a pull request. You write the server once, and every MCP-compatible app can use it.

// Why it matters

AI models are smart but isolated. On their own they cannot see your files, query your database, or hit a live API. To make a model useful you have to connect it to the outside world — that connection is what we call tool use. The problem is the number of connections.

Before MCP, every connection was bespoke. If you had M AI apps and N tools you wanted to reach, you faced roughly M times N custom integrations — each one a different SDK, auth scheme, and data format. Add a new tool and you rewrite it for every app. Add a new app and you re-plumb every tool. This is the classic combinatorial mess, and it is why most assistants could only touch the handful of services their vendor had hand-wired.

MCP turns M times N into M plus N. Each app implements the protocol once; each tool ships one server once; everything interoperates. That is the whole pitch — and it is why an ecosystem of community servers appeared so fast. You should care if you build AI agents, if you maintain a service you want assistants to reach, or if you just want your AI app to use the tools you pick instead of the ones a vendor chose.

// How it works

MCP is a client-server protocol. The host (the AI app) runs an MCP client for each server it connects to. The two sides talk using JSON-RPC 2.0 — a simple, well-established format for sending named requests and getting responses back. There is nothing AI-specific about the wire format; the magic is in what the messages describe.

The three server primitives

A server can expose three kinds of thing. These are the core vocabulary of MCP:

Tools are the ones agents lean on most — they are MCP's version of function calling. Each tool carries a name, a description, and a JSON Schema inputSchema so the model knows exactly what arguments to pass.

Discovery, then call

The flow is always: discover first, call second. When a host connects, it sends an initialize request and the two sides negotiate which features they support (capability negotiation). Then the host calls tools/list to find out what tools exist — it does not have to know them in advance. When the model decides to use one, the host sends tools/call with the chosen name and arguments. The server runs it and returns the result, which the host feeds back to the model. If the server's toolset changes, it can send a tools/list_changed notification so the host refreshes — tools can appear and disappear at runtime.

Transports: where the server runs

The same JSON-RPC messages travel over two transports. stdio runs the server as a local subprocess and pipes messages through standard input/output — fast, no network, perfect for a filesystem or git server on your own machine. Streamable HTTP runs the server remotely and talks over HTTP (with Server-Sent Events for streaming), so a hosted service can serve many clients at once and use normal auth like OAuth bearer tokens. Local-vs-remote is purely about the transport; the protocol on top is identical.

// A minimal MCP server

Here is a tiny server in Python using the official mcp SDK. It exposes one tool, add, that adds two numbers. This is the whole thing — the SDK handles JSON-RPC, discovery, and the lifecycle handshake for you.

# pip install "mcp[cli]"
from mcp.server.fastmcp import FastMCP

# Name your server. The host shows this to the user.
mcp = FastMCP("demo")

@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two integers and return the sum."""
    # The docstring becomes the tool description the model reads.
    # Type hints become the JSON Schema for the arguments.
    return a + b

if __name__ == "__main__":
    # Run over stdio so a local host can launch it as a subprocess.
    mcp.run(transport="stdio")

To use it, you register the server with an MCP host. Most hosts read a small JSON config that tells them how to launch the process. A stdio entry just names the command and arguments:

{
  "mcpServers": {
    "demo": {
      "command": "python",
      "args": ["server.py"]
    }
  }
}

Now any model running in that host can discover the add tool and call it. Notice what you did not write: no API endpoint, no auth glue, no per-app code. The same server.py works in Claude Desktop, VS Code, Cursor, or your own agent — that is the payoff of a shared protocol.

// MCP vs. plain function calling

If you already know function calling, a fair question is: why do I need MCP at all? Both let a model invoke a tool. The difference is where the tool definition lives and who can reuse it.

Function calling is the model-side mechanism: the LLM emits a structured request to run a named function. MCP is the connection layer that delivers tools to the model and runs them. In practice they compose — a host discovers tools over MCP, hands their schemas to the model as functions, and routes the model's function call back through MCP to the right server. MCP did not replace function calling; it gave it a portable plug.

// Common pitfalls and gotchas

• Treating servers as trusted. An MCP server runs code and can return arbitrary text into the model's context. A malicious or compromised server can attempt prompt injection — hiding instructions in a tool result to hijack the agent. Only install servers you trust, and review what they return.
• Too many tools. Every tool's name and description is loaded into the model's context window. Connect ten chatty servers and you can bury the model in dozens of tools, hurting accuracy and cost. Enable only the servers a given task needs.
• Confusing client and server. The server exposes tools; the host/client is the AI app. People often say 'MCP client' when they mean the host. The host runs one client per connected server.
• Skipping auth on remote servers. A stdio server inherits your local permissions, which is risky enough. A remote HTTP server is a network service — put real auth (OAuth/bearer tokens) in front of it, never an open endpoint.
• Assuming every host supports every primitive. Hosts negotiate capabilities at connect time. A host might support tools but ignore resources or prompts. Check what your target host actually consumes.

// Going deeper

Beyond the three server primitives, MCP defines client primitives that let a server ask the host for things — this is where the protocol gets genuinely powerful for agent builders.

• Sampling — a server can ask the host to run an LLM completion on its behalf (sampling/createMessage). This lets a server use a model without bundling its own model SDK or API key, staying provider-neutral. The host stays in control of cost and which model runs.
• Elicitation — a server can pause and ask the user for more input or confirmation (elicitation/create), e.g. 'this will delete 200 rows, proceed?'. Useful for human-in-the-loop safety on destructive tools.
• Logging — servers can stream structured log messages back to the host for debugging and observability.

MCP is stateful: a connection is initialized, capabilities are negotiated, and the session persists. That is a feature (real-time */list_changed notifications, progress updates on long calls) but also a production concern — remote servers must manage many concurrent sessions, and the Streamable HTTP transport allows a stateless subset for horizontal scaling. There is also experimental work on Tasks, durable wrappers that let a client kick off an expensive operation and poll for the result later instead of blocking.

Production and security concerns

Because a server mediates real systems, the security surface is real. Tool-result text flows straight into the model, so injection and data-exfiltration are live risks; treat every server boundary the way you would treat untrusted user input. For remote servers, MCP leans on standard HTTP auth and recommends OAuth for token acquisition. Scope tokens tightly, audit what each tool can reach, and prefer read-only resources over write tools where you can. When you compose MCP into a larger system, the same care you apply to agent planning and multi-agent systems — least privilege, confirmation gates, observability — applies double once an agent can act on the world through tools.

Where to go next: explore the MCP subcategory for building and securing servers, and read the official spec to see the exact JSON-RPC schema for every method. The protocol versions by date (e.g. 2025-06-18), so check which version your host and SDK target.