Model Context Protocol (MCP)

Why a protocol?

Function calling gives a model the ability to use tools, and says nothing about how those tools are packaged, discovered or shared. Each application invents its own glue. With M applications and N systems, that is M times N integrations, each with its own authentication, its own format for errors, and its own bugs.

The Model Context Protocol (MCP) is an open protocol, introduced by Anthropic in late 2024 and since adopted widely across AI applications, IDEs and agent frameworks. It standardises how an AI application connects to external tools and data. The integration problem falls to M plus N: every application implements the client side once, every system is wrapped as a server once, and everything interoperates. There is a public ecosystem of servers for source control, databases, ticketing, observability, cloud platforms and much else, and you can write your own in an afternoon.

MCP covers only the exchange of context. It does not dictate which model you use, how you prompt it, or how your agent loop works. Your application still takes the tools that a server offers, passes their definitions to the model as in the previous module, and carries out the model's tool calls, now by forwarding them to the server.

Host, client, server

A host creates one client for each server it connects to, so a host with four servers runs four clients. The word "server" describes the role and not the location. There are two standard transports.

Beneath either transport, the messages are JSON-RPC 2.0: requests that carry an id and expect a response, and notifications that have no id and expect nothing. Because the message format is the same on both transports, a server written for stdio can be offered over HTTP without changing its tools.

Three primitives, three kinds of control

A server can offer three kinds of thing. The distinction that matters is who decides when each one is used.

A server for a database shows the difference well. It could offer a tool run_query for the model to call, a resource db://schema that the application loads so that the model knows the tables, and a prompt explain-slow-query that a user selects from a menu. Resources have URIs, such as file:///docs/runbook.md, and resource templates add parameters, as in logs://{service}/{date}.

Discovery is dynamic. A client calls the */list methods to learn what a server offers, and it can subscribe to change notifications, such as notifications/tools/list_changed, so that it can refresh its list when the server's offering changes. In the other direction, a server can ask the user for additional input through elicitation, for instance to confirm an action. In practice most servers offer only tools, which is a perfectly good place to start.

What goes over the wire

You will rarely write these messages by hand, and reading them makes debugging much easier. A client first finds out what tools exist.

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "get_error_rate",
        "title": "Service error rate",
        "description": "Returns the fraction of failed requests for a service over a recent window.",
        "inputSchema": {
          "type": "object",
          "properties": {
            "service": { "type": "string", "description": "Deployed service name" },
            "window_minutes": { "type": "integer", "minimum": 1, "maximum": 1440 }
          },
          "required": ["service", "window_minutes"]
        }
      }
    ]
  }
}

This is the tool definition from the previous module in the same three parts: a name, a description and a JSON Schema, which MCP calls inputSchema. The host hands these definitions to its model. When the model asks for a tool, the host's client sends a tools/call request.

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "get_error_rate",
    "arguments": { "service": "checkout", "window_minutes": 15 },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "oncall-assistant", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      { "type": "text", "text": "{\"error_rate\": 0.042, \"window_minutes\": 15, \"requests\": 18400}" }
    ]
  }
}

A result is an array of content items, which may be text, images or references to resources. A tool that fails in the ordinary course of its work should report the failure inside the result, flagged as an error, so that the model can read it and recover, which is the same principle as returning errors as data in the previous module. Errors at the protocol level, such as an unknown method, come back as JSON-RPC errors.

Building a server

The official SDKs take care of the protocol, the transports and the generation of schemas. In Python, you decorate ordinary typed functions, and the SDK builds the tool's name, description and input schema from the function's name, its docstring and its type hints.

uv init oncall-mcp && cd oncall-mcp
uv venv && source .venv/bin/activate
uv add "mcp[cli]"

import logging

from mcp.server import MCPServer

logging.basicConfig(level=logging.INFO)          # logging goes to stderr, never to stdout
log = logging.getLogger(__name__)

mcp = MCPServer("oncall-tools")

KNOWN_SERVICES = {"checkout", "orders-api", "payments"}


@mcp.tool()
def list_services() -> list[str]:
    """List the names of all the services that can be queried."""
    return sorted(KNOWN_SERVICES)


@mcp.tool()
def get_error_rate(service: str, window_minutes: int = 15) -> dict:
    """Return the fraction of failed HTTP requests (5xx) for a service over a recent window.

    Use this to check whether a service is healthy. The result is a number from 0 to 1,
    where 0.02 means that 2% of requests failed. Data is about one minute behind real time.

    Args:
        service: Service name exactly as it is deployed, e.g. 'checkout'. Call list_services if unsure.
        window_minutes: How far back to look, from 1 to 1440. Use 15 for the current state.
    """
    if service not in KNOWN_SERVICES:
        raise ValueError(f"Unknown service '{service}'. Known: {sorted(KNOWN_SERVICES)}")
    if not 1 <= window_minutes <= 1440:
        raise ValueError("window_minutes must be between 1 and 1440")
    log.info("error rate requested for %s over %s min", service, window_minutes)
    return {"service": service, "error_rate": query_metrics(service, window_minutes),
            "window_minutes": window_minutes}


if __name__ == "__main__":
    mcp.run(transport="stdio")

To use a local server, you register it in the host's configuration. Most hosts use a JSON block of roughly this shape, which tells the host which command to launch.

{
  "mcpServers": {
    "oncall-tools": {
      "command": "uv",
      "args": ["--directory", "/absolute/path/to/oncall-mcp", "run", "server.py"],
      "env": { "METRICS_TOKEN": "read-only-token-from-your-secret-store" }
    }
  }
}

• Test with the MCP Inspector, a development tool that connects to your server, lists its tools, and lets you call them by hand, before you involve any model.
• Everything from the previous module still applies: descriptions are prompts, results should be small and labelled, and errors should be readable by the model.
• SDK class and method names change as the protocol evolves. At the time of writing, the Python SDK's high-level class is MCPServer, and in earlier releases it was called FastMCP. Check the SDK's current documentation when you start.

Security: you are plugging code into a model

Connecting an MCP server is installing software, and it deserves the scrutiny of the supply chain module. A local server runs on your machine with your user's privileges. A remote server sees whatever your host sends to it. And every server adds text, namely tool descriptions and results, to your model's context, where that text can influence what the model does.

• Start read-only. A server that can only read can leak, and it cannot destroy. Add write tools one at a time, each behind the host's approval prompt.
• Keep a person in the loop for actions that have consequences. MCP expects hosts to show users which tools exist, and to ask for consent before sensitive calls. Do not switch those prompts off for convenience.
• Never place secrets in tool descriptions or results. Give the server its credentials through environment variables or a secret store, and keep tokens out of any configuration file that is committed to a repository.
• Validate inside the server, however well the client behaves. Anyone who can reach a remote server can send it arbitrary requests.
• Log every tool call on the server side, with the identity of the caller, for audit.
• Limit the number of connected servers. Every tool definition costs tokens on every request, and a large, overlapping set of tools reduces the accuracy of selection as well as widening the attack surface.