Model Context Protocol (MCP)

The big idea

You want your chat assistant to read your files, your IDE assistant to query your database, and both to file tickets in your issue tracker. Without a standard, every app writes its own connector for every system: three apps and five systems means fifteen integrations, each with its own tool schemas and auth code.

The Model Context ProtocolAn open standard, introduced by Anthropic in November 2024, that defines how AI applications discover and use tools, data and prompt templates offered by separate programs called MCP servers. (MCP) turns that into "write once, use anywhere". You wrap a system in an MCP server once; any MCP-compatible application can connect to it, discover what it offers, and hand its tools to the model. Three apps and five systems becomes five servers plus MCP support in three apps.

The usual analogy is a USB port. Before USB, every device had its own plug. With a standard port, the laptop maker and the device maker each build to one specification, and anything plugs into anything. What the laptop lets a device do is still the laptop's decision.

How it works

Hosts, clients and servers

Three roles, in the protocol's own terms:

• The hostIn MCP, the AI application the user works in, such as a chat app or an IDE, which runs MCP clients, decides which servers to connect to and controls what the model may do. is the AI application: a chat app, an IDE, an agent. It owns the model conversation and the user interface, and it decides which servers to trust.
• An MCP clientIn MCP, the component inside the host that holds one dedicated connection to one MCP server and relays requests and results. lives inside the host and holds one dedicated connection to one server. Three servers means three clients.
• An MCP serverIn MCP, a program that offers tools, resources and prompts to MCP clients, usually wrapping one system such as a file store, a database or a SaaS API. is a program that exposes some capability: a file store, a database, a ticketing system.

Messages between client and server are JSON-RPC 2.0A lightweight remote procedure call format in which each request is a JSON object with a method name, parameters and an id, and each response carries the same id with a result or an error.: each request names a method, such as tools/list or tools/call, with parameters and an id; each response carries the same id and a result or an error.

Three things a server can offer

The protocol separates what a server offers by who decides to use it:

• Tools are functions the model decides to call, such as search_flights or create_ticket. They can change things. The host lists them with tools/list and runs one with tools/call, and each tool has a name, a description and an input JSON Schema, just as in Function calling and tool use .
• Resources are read-only data the application chooses to include as context, such as a file's contents or a database schema. Each has a URI, like file:///docs/readme.md, and templates such as travel://activities/{city} cover families of them.
• Prompts are reusable instruction templates the user picks, often shown as slash commands or menu items, such as "summarize my meetings".

Transports: stdio and HTTP

How the JSON-RPC messages travel is the transport:

• stdio: the host launches the server as a local child process and they exchange messages over standard input and output. No network, no ports. A local stdio server typically serves one client. Good for files, local databases and developer tools.
• Streamable HTTP: the server runs remotely, clients send HTTP POST requests, and the server can stream responses with Server-Sent Events. One remote server serves many clients, so it needs authentication; MCP recommends OAuth to obtain tokens.

What the host does with all this

At startup the host connects to each configured server and asks what it offers. It merges every server's tools into the tool list it sends to the model. When the model proposes a call, the host finds which server owns that tool, checks its own policy (and often asks the user), sends tools/call through the right client, and puts the result back in the conversation. The model never talks to a server directly. The tool-call loop is exactly the one from Function calling and tool use ; MCP standardizes the plumbing behind it.

Try it

Try this:

1. Sort all eight. search_code is read-only, so why is it a tool and not a resource? (Who decides to use it?)
2. Which of the three kinds can change things in the world? Those are the ones a host should put behind approval.

Below is a tiny server and client speaking the wire format by hand over stdio. The client launches the server as a child process, discovers its tools, calls one twice, and tries a method the server does not have.

# A tiny MCP-style server speaking JSON-RPC 2.0 over stdio, and a client that launches it.
# Real servers use an official SDK, which also handles version discovery and capabilities.
import json, subprocess, sys
TOOLS = [{"name": "get_weather", "description": "Current weather for a city (fake data)",
          "inputSchema": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]}}]
FAKE = {"Oslo": "6 C, rain", "Rome": "21 C, dry"}
def handle(req):                                  # server side: one JSON-RPC request -> response
    if req["method"] == "tools/list":
        result = {"tools": TOOLS}
    elif req["method"] == "tools/call":
        city = req["params"]["arguments"].get("city", "")
        ok = city in FAKE
        result = {"content": [{"type": "text", "text": FAKE.get(city, f"unknown city {city!r}")}], "isError": not ok}
    else:
        return {"jsonrpc": "2.0", "id": req["id"], "error": {"code": -32601, "message": "Method not found"}}
    return {"jsonrpc": "2.0", "id": req["id"], "result": result}
if sys.argv[1:] == ["serve"]:                     # stdio transport: one JSON message per line
    for line in sys.stdin:
        print(json.dumps(handle(json.loads(line))), flush=True)
    sys.exit()
server = subprocess.Popen([sys.executable, __file__, "serve"], stdin=subprocess.PIPE,
                          stdout=subprocess.PIPE, text=True)   # the client launches the server
def rpc(i, method, params=None):                  # client side
    msg = {"jsonrpc": "2.0", "id": i, "method": method, "params": params or {}}
    server.stdin.write(json.dumps(msg) + "\n"); server.stdin.flush()
    return json.loads(server.stdout.readline())
tools = rpc(1, "tools/list")["result"]["tools"]
print("discovered:", [t["name"] for t in tools])   # the host hands these schemas to the model
for i, city in enumerate(["Oslo", "Atlantis"], start=2):
    res = rpc(i, "tools/call", {"name": "get_weather", "arguments": {"city": city}})["result"]
    print(f"tools/call {city}: {res['content'][0]['text']}  isError={res['isError']}")
print("unknown method:", rpc(9, "files/delete")["error"]["message"])
server.stdin.close(); server.wait()

discovered: ['get_weather']
tools/call Oslo: 6 C, rain  isError=False
tools/call Atlantis: unknown city 'Atlantis'  isError=True
unknown method: Method not found

The unknown city comes back as a normal result with isError set, which the model can read and recover from. The unknown method is a protocol error, which the client handles. A real server would use an official SDK, where a decorated Python function becomes a tool and the SDK handles discovery and versions.

Going deeper

Security considerations

MCP makes it easy to connect powerful capabilities, which makes it easy to connect dangerous ones.

• Every server is code you run or trust. A local stdio server runs on your machine with your permissions. Install servers only from sources you trust, and the specification requires clients that offer one-click local server setup to show a clear consent dialog before running the command.
• Keep a human in the loop. The specification says there should always be a human able to deny tool invocations. Hosts typically show the tool name and arguments before running anything that writes, sends or deletes.
• Descriptions are untrusted input. Tool descriptions and tool results enter the model's context, so a malicious or compromised server can inject instructions there ( Prompt injection and data exfiltration ). Clients must treat tool annotations as untrusted unless the server is trusted.
• Watch the combination. A server that reads private data plus a server that reads untrusted web content plus any way to send data out is the recipe for data exfiltration, even if each server is harmless alone.
• Least privilege for tokens. Remote servers should request narrow scopes, validate that tokens were issued to them, and never pass a client's token straight through to another API, an anti-pattern the MCP security guide calls token passthrough.

Build vs connect

Many popular systems already have MCP servers, so connecting is often a configuration change. Write your own server when you want to expose an internal system once to every AI tool your team uses. Keep it small: a few well-described tools ( Making agents reliable ) beat a server that mirrors every endpoint of an API.

Trade-offs

Common mistakes

• Installing a third-party server without reading what it does or what it can access.
• Auto-approving every tool call, including ones that send, pay or delete.
• Connecting so many servers that the model sees dozens of overlapping tools and picks the wrong one.
• Treating tool descriptions and tool results from a server as trusted instructions.
• Passing a user's access token through a server to a downstream API instead of using properly scoped tokens.

In the wild

Check yourself

Recap