Model Context Protocol (MCP) in Production

IN SHORT

The Model Context Protocol (MCP) is an open protocol that standardises how AI applications connect to tools and data. A client inside the AI application talks to MCP servers that expose capabilities.
MCP servers offer three main primitives: tools the model can call, resources it can read, and prompts (reusable templates). Messages use JSON-RPC 2.0 over stdio for local servers or HTTP for remote ones.
MCP solves integration once per system instead of once per app. It does not decide who may call what: permissions, effect classes and approvals are still your job.
Treat every MCP server as a production service: scoped credentials, versioned tool definitions, logs per call, and no unreviewed third-party servers near sensitive data.

Before the Model Context Protocol, every AI application wired up its own integrations. A Slack connector for one assistant, a different Slack connector for the next, each with its own auth, its own tool descriptions and its own bugs. MCP's pitch is simple: write the integration once as a server, and any compatible client can use it.

01What is the Model Context Protocol?

The Model Context Protocol is an open protocol, introduced by Anthropic in late 2024 and since adopted widely, for connecting AI applications to external systems. It has three roles:

Host: the AI application the user is working in (a chat app, an IDE, an agent runtime).
Client: the connector inside the host that keeps a session with one server.
Server: a program that exposes capabilities from some system, such as a database, a ticketing tool or a file store.

Messages are JSON-RPC 2.0. A local server usually runs as a subprocess over stdio; a remote server is reached over HTTP. On connect, client and server negotiate capabilities, and the client discovers what the server offers.

02What can a server expose?

Three main primitives:

Primitive	Who decides to use it	Example
Tools	The model, during a task	`create_ticket`, `query_orders`
Resources	The application or user, as context	A file, a schema, a record
Prompts	The user, as a template	“Summarise this incident”

Tools are the part that changes the world, so they get most of the scrutiny. A tool has a name, a description and a JSON schema for its input, much like function calling, but discovered at runtime from the server.

servers/orders_mcp.py

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("orders")

@mcp.tool()
def lookup_order(order_id: str) -> dict:
    """Look up an order by id. Read-only. Returns status, total and payment state."""
    return orders.get(order_id, scope=current_user_scope())

@mcp.resource("orders://schema")
def order_schema() -> str:
    """The orders table schema, for context."""
    return ORDER_SCHEMA_DOC

if __name__ == "__main__":
    mcp.run()   # stdio by default

03What does MCP not solve?

It standardises the plumbing. It does not make any of these decisions for you:

Who may call what. The protocol carries the call; your server decides whether this user may make it. Run tools with the acting user's credentials, not a shared admin token. Remote servers should use proper authorisation (the spec builds on OAuth) rather than a static key pasted into a config file.

What happens if a call runs twice. MCP has no notion of effect classes. A create_refund tool still needs idempotency keys and an approval rule, enforced in the server or the runtime around it.

Whether the tool description is honest. The model reads tool descriptions as instructions. A malicious or careless server can describe a tool misleadingly, or return results that contain injected instructions. Third-party servers are third-party code with a direct line to your model.

Versioning. If a server renames a tool or changes its schema, every agent prompt and eval that relied on the old shape can break silently. Version tool definitions and test them like an API.

MCP makes a tool easy to connect. It does not make it safe to call.

04How should a team run MCP servers?

The same way it runs any service that other systems depend on:

Own each server. A named owner, a repo, a deploy pipeline, and a changelog for tool definitions.
Least privilege. Separate read-only servers from ones that write. Many agents only ever need the read-only one.
Log every call with the user, the tool, the arguments and the outcome, so an incident can be traced.
Allowlist servers per agent instead of letting an agent discover everything available.
Review third-party servers before connecting them to anything sensitive, and pin their versions.

05Where it sits in the stack

MCP lives at L4 actions, where tools and integrations sit, and touches L1 data and knowledge through resources. It is a genuine step forward: integration work drops sharply when a capability is built once and reused everywhere. The engineering that keeps actions safe, from permissions to approvals to durable retries, still sits around it.