What is the Model Context Protocol (MCP)?

MCP is an open standard that defines how an AI application connects to external tools, data sources, and prompts. Instead of hand-wiring every model to every integration, a host app connects to MCP servers that expose their capabilities through one uniform interface, so any MCP-compatible model can use any MCP server.

What are the primitives in MCP?

An MCP server exposes three kinds of capability: Tools (functions the model can call to take actions), Resources (data the app can read, like files or database rows), and Prompts (reusable prompt templates the user can invoke). The client discovers these at connection time and offers them to the model.

Handbooks / Model Context Protocol

AI Engineering~11 min readIntermediate

Deep Dive

The Model Context Protocol,
the USB-C for AI tools.

Q: What problem does MCP solve?

Without a standard, connecting M AI apps to N tools needs M×N bespoke integrations. MCP collapses that to M+N: each app speaks MCP once, each tool exposes an MCP server once, and they interoperate. It decouples the model from the integrations the way a common port decouples a laptop from its peripherals.

Q: Is MCP a security risk?

MCP is transport, not a safety guarantee. A server can expose powerful tools and can return content that carries a prompt injection, so the same defenses apply: least-privilege tools, human approval for dangerous actions, sandboxing, and treating server output as untrusted data. Connecting to a malicious or compromised MCP server is a real risk to manage.

Every agent needs to reach the outside world — files, APIs, databases, other apps. MCP is the open standard that lets any model talk to any tool through one common port, instead of a snarl of one-off integrations. Here's what it is, how it works, and when to reach for it.

The M×N integration problem

Give a model tools and it becomes an agent — it can search, read a file, query a database, send a message. But every one of those connections used to be bespoke glue: this model's tool-calling format, that API's auth, a custom adapter in between. With M AI apps and N tools, you're on the hook for M × N integrations, each maintained by hand.

→ The core idea

MCP turns M × N into M + N. Each app learns to speak MCP once; each tool exposes an MCP server once; everything interoperates. It's the same move USB made for peripherals — a common port, so the laptop doesn't need a driver for every device.

Announced by Anthropic in late 2024 and adopted broadly since, MCP is an open protocol: not tied to one model vendor, one language, or one product. That neutrality is the whole point — an ecosystem only forms if the standard belongs to everyone.

Host, client, and server

MCP has three roles. The host is the AI application the user interacts with (a chat app, an IDE agent, a desktop assistant). Inside it, an MCP client manages a connection to each MCP server — a separate process or service that exposes some capability. One host can hold many clients, each wired to a different server.

One host, many servers

HostThe AI app the user sees — owns the model and the conversation.

ClientA connector inside the host, one per server, speaking MCP.

ServerAn external provider of tools / data / prompts — a filesystem, GitHub, a database, your own service.

Under the hood it's JSON-RPC 2.0 messages over a transport — typically stdio for a local server the host launches, or HTTP with Server-Sent Events for a remote one. The wire format is deliberately boring; the value is in the shared vocabulary on top.

The three primitives

Every MCP server exposes some mix of three capability types — the nouns of the protocol.

What a server can offer

Tools

Functions the model can call
Take actions with side effects
e.g. create a file, send an email
Model-controlled

Resources

Read-only data the app can load
Files, rows, API responses
Addressed by URI
App-controlled

Prompts are the third: reusable, parameterized prompt templates a server publishes and the user can invoke (a "/summarize" command, a code-review template). The split matters — tools are chosen by the model, resources are supplied by the app, and prompts are triggered by the user. Keeping those lines clear is also a security boundary.

→ Mental model

A tool is a verb the model may use; a resource is a noun the app may read; a prompt is a shortcut the user may run. Same server, three different kinds of capability, three different controllers.

How a session works

The lifecycle is short and predictable. The client and server first initialize, exchanging protocol versions and capabilities — a negotiation so each side knows what the other supports. Then the client discovers what's on offer (tools/list, resources/list, prompts/list) and presents the tools to the model.

Connect → discover → call

1initialize — agree on version and capabilities.

2tools/list — the client learns the available tools and their JSON schemas.

3model decides — it emits a tool call in its own format; the client maps it to MCP.

4tools/call — the server runs it and returns a result.

5observe — the result goes back into the model's context, and the loop continues.

Because discovery happens at runtime, tools can appear and disappear without redeploying the host — plug in a new server and its capabilities show up. That dynamic quality is what makes MCP feel less like an API client and more like plugging in a device.

The wire format is just JSON-RPC 2.0

There is no mystery under the hood. Every MCP message is a JSON-RPC 2.0 envelope: a request carries an id and a method (plus optional params); the response echoes the same id and returns either a result or an error. The whole protocol is a handful of method names over that envelope:

Method	Sent by	Does	Returns
initialize	Client	Agree protocol version, exchange capabilities	serverInfo, capabilities
notifications/initialized	Client	Signal the handshake is done (a notification — no id, no reply)	—
tools/list	Client	Discover tools and their JSON schemas	array of tool defs
tools/call	Client	Invoke one tool with arguments	content blocks
resources/list, prompts/list	Client	Same discovery pattern for the other two primitives	arrays

A notification (like notifications/initialized) is a request with no id — the server must not reply to it. That's the one wrinkle in an otherwise request/response protocol. Here is a real tools/call round-trip, byte for byte:

// client → server { "jsonrpc": "2.0", "id": 3, "method": "tools/call", "params": { "name": "add", "arguments": { "a": 2, "b": 40 } } } // server → client (note: same id: 3) { "jsonrpc": "2.0", "id": 3, "result": { "content": [ { "type": "text", "text": "42" } ], "isError": false } }

The result is a list of typed content blocks, not a bare value — so a tool can return text, images, or embedded resources through the same shape.

Call a method the server doesn't implement and you get the standard JSON-RPC error, code -32601 ("Method not found") — same code you'd see from any JSON-RPC service, because MCP is one. That's the whole point: MCP didn't invent a transport, it standardized a small vocabulary on top of a boring, proven one.

When to use it — and the sharp edges

Reach for MCP when you want your agent to use tools that others can build and share, or to reuse a growing ecosystem of servers instead of writing every integration yourself. For a single hard-coded tool in one app, a direct function-calling schema is simpler; MCP earns its keep once integrations multiply or need to be swapped without a redeploy.

→ Security is not free

MCP is a transport, not a safety layer. A server can expose dangerous tools, and any content it returns is untrusted input that can carry a prompt injection. The usual defenses still apply: least-privilege tools, human approval for risky actions, sandboxed execution, and treating a third-party server as you would any external dependency you didn't write.

MCP is one station in building a real agent runtime — the connective tissue between the model and the world. The rest of that runtime (the loop, context, memory, evals, cost) is the AI Harness roadmap.

RUN IT YOURSELF

An MCP server in 50 lines

The protocol is small enough to hold in your head — so build the whole thing. This is a real MCP-style server: a single handle(request) function that speaks JSON-RPC 2.0. Run it and watch a full session on the wire — initialize, tools/list, tools/call, and an unknown method returning the standard -32601 error. There is no framework here and none is hiding: this is the protocol. Add a tool to TOOLS and it shows up in discovery on the next run.

CPython · WebAssembly

import json

# MCP rides on JSON-RPC 2.0: a request has an id + method (+ params); a
# response echoes the id and returns either "result" or "error".
PROTOCOL_VERSION = "2025-06-18"

TOOLS = {
    "add":  {"description": "Add two numbers",
             "inputSchema": {"type": "object",
                 "properties": {"a": {"type": "number"}, "b": {"type": "number"}},
                 "required": ["a", "b"]},
             "run": lambda a, b: a + b},
    "echo": {"description": "Echo a string back",
             "inputSchema": {"type": "object",
                 "properties": {"text": {"type": "string"}}, "required": ["text"]},
             "run": lambda text: text},
}

def ok(id, result):        return {"jsonrpc": "2.0", "id": id, "result": result}
def err(id, code, msg):    return {"jsonrpc": "2.0", "id": id, "error": {"code": code, "message": msg}}

# The whole server. Request in, response out. This IS the protocol.
def handle(req):
    id, method, params = req.get("id"), req.get("method"), req.get("params", {})
    if method == "initialize":
        return ok(id, {"protocolVersion": PROTOCOL_VERSION,
                       "capabilities": {"tools": {}},
                       "serverInfo": {"name": "demo-server", "version": "0.1.0"}})
    if method == "tools/list":
        return ok(id, {"tools": [
            {"name": n, "description": t["description"], "inputSchema": t["inputSchema"]}
            for n, t in TOOLS.items()]})
    if method == "tools/call":
        name, args = params.get("name"), params.get("arguments", {})
        if name not in TOOLS:
            return err(id, -32602, "Unknown tool: " + str(name))
        value = TOOLS[name]["run"](**args)
        return ok(id, {"content": [{"type": "text", "text": str(value)}], "isError": False})
    return err(id, -32601, "Method not found: " + str(method))   # JSON-RPC standard code

# convenience wrappers used below and by the tests
def initialize():        return handle({"jsonrpc": "2.0", "id": 1, "method": "initialize", "params": {}})
def list_tools():        return handle({"jsonrpc": "2.0", "id": 2, "method": "tools/list"})
def call_tool(name, **a):return handle({"jsonrpc": "2.0", "id": 3, "method": "tools/call",
                                        "params": {"name": name, "arguments": a}})

# --- drive a whole session and print the real wire messages ---
def show(label, req):
    print(label)
    print("  >>", json.dumps(req))
    print("  <<", json.dumps(handle(req)))
    print()

show("1. initialize", {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"capabilities":{}}})
show("2. tools/list", {"jsonrpc":"2.0","id":2,"method":"tools/list"})
show("3. tools/call add(2,40)", {"jsonrpc":"2.0","id":3,"method":"tools/call",
                                 "params":{"name":"add","arguments":{"a":2,"b":40}}})
show("4. unknown method", {"jsonrpc":"2.0","id":4,"method":"tools/teleport"})

Put MCP to work

Tool Schema Designer — design a tool Lab — the agent loop MCP feeds Lab — the injection surface Design an AI Agent The AI Harness Roadmap

Frequently asked

Quick answers

What is the Model Context Protocol?

An open standard for how an AI app connects to external tools, data, and prompts. A host connects to MCP servers that expose capabilities through one uniform interface, so any MCP-compatible model can use any MCP server.

What problem does MCP solve?

It turns M×N bespoke integrations into M+N: each app speaks MCP once, each tool exposes a server once, and they interoperate — decoupling the model from the integrations like a common port decouples a laptop from its peripherals.

What are the primitives?

Tools (functions the model can call), Resources (read-only data the app can load), and Prompts (reusable templates the user can invoke). The client discovers them at connection time and offers the tools to the model.

Is MCP a security risk?

MCP is transport, not a safety guarantee. Servers can expose powerful tools and return content that carries a prompt injection, so least-privilege tools, human approval, sandboxing, and treating server output as untrusted all still apply.

Finished this one? 0 / 208 Handbooks done

Explore the topic

See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.

AI Agents & Tools

The Model Context Protocol,
the USB-C for AI tools.

The M×N integration problem

Host, client, and server

The three primitives

Tools

Resources

How a session works

The wire format is just JSON-RPC 2.0

When to use it — and the sharp edges

An MCP server in 50 lines

Quick answers

What is the Model Context Protocol?

What problem does MCP solve?

What are the primitives?

Is MCP a security risk?

Explore the topic

More Handbooks

Explore more from Vibe Engines

The Model Context Protocol,the USB-C for AI tools.

The M×N integration problem

Host, client, and server

The three primitives

Tools

Resources

How a session works

The wire format is just JSON-RPC 2.0

When to use it — and the sharp edges

An MCP server in 50 lines

Quick answers

What is the Model Context Protocol?

What problem does MCP solve?

What are the primitives?

Is MCP a security risk?

Explore the topic

More Handbooks

Explore more from Vibe Engines

The Model Context Protocol,
the USB-C for AI tools.