What is MCP? Model Context Protocol Explained for AI Engineers

The Model Context Protocol (MCP) is an open, vendor-neutral standard for connecting AI applications to external tools, data and prompt templates. A server exposes capabilities over JSON-RPC; a client, usually an agent or an IDE, discovers them at runtime and calls them. You write a tool server once and any MCP-compatible client can use it, which removes the per-framework tool code that used to be the most duplicated part of an agent stack. It is worth adopting when tools are shared across more than one agent or product, when you connect to enterprise systems, or when you want a security boundary between the model and the systems it touches. It is not worth adopting for a single agent with two simple functions.

Before MCP, every agent framework and every model vendor had its own way of describing a tool. A function that queried Postgres had to be wrapped once for OpenAI function calling, again for a LangChain tool, again for a custom agent loop, and again when a second team wanted it in a different product. The wrapper was never the interesting part, but it consumed real engineering time, and each copy drifted from the others.

The result was an N times M problem. N agents, M tools, N times M integrations. Every new tool had to be integrated into every agent. Every new agent had to re-implement every tool.

MCP turns this into N plus M. Each tool is served once. Each agent speaks the protocol once. After that, any agent can use any tool without either side knowing about the other in advance.

An MCP server can expose three kinds of capability. Most production servers use the first, some use the second, and the third is underused.

Tools

Tools are functions the model can call. Each has a name, a natural-language description, and a JSON Schema for its input. The description is what the model reads when deciding whether to call it, so it is the most important line of code in the server. "Query the customer database" is weak. "Look up a customer by email or customer ID and return their plan, status and open tickets. Use this before answering any billing question." tells the model when and why.

Tools can have side effects. A tool that creates a ticket or sends an email is a tool. The protocol has annotations for whether a tool is read-only or destructive, and a well-behaved client surfaces that to the user or to an approval step.

Resources

Resources are data the client can read, identified by a URI. A file, a database row, a log stream, a document. Resources are read-only from the model's point of view and are meant to be loaded into context by the application, not called like a function. A resource lets a client show a user "here is the document the agent is looking at" without the model having to fetch it through a tool.

Prompts

Prompts are reusable templates the server offers to the client. A server for a code review tool might expose a "review this pull request" prompt that takes a PR number and expands into a full instruction set. This is how a tool author ships the instructions that make their tool work well, instead of hoping every client writes them from scratch.

The wire protocol is JSON-RPC 2.0. The sequence for a single session is short.

The important design choice is in step three. MCP is a protocol between the application and the tool server. It is not a protocol between the model and the tool. That keeps it independent of any particular model vendor's function-calling format.

MCP defines how messages are framed, not how bytes move. Two transports are standard.

Standard input and output is for local servers. The client launches the server as a child process and exchanges JSON-RPC over stdin and stdout. This is how IDE integrations and desktop assistants typically run tool servers. It is simple, needs no network, and inherits the user's local permissions, which is both its strength and its risk.

Streamable HTTP is for remote servers. The client sends requests over HTTP and the server can stream responses back, including server-initiated messages. This is the transport for shared, hosted tool servers used by many clients, and it is where authentication and authorisation actually matter.

Choose stdio for developer tooling on one machine. Choose HTTP for anything shared, anything in production, and anything that touches an enterprise system.

Adopting a protocol is never free. Three costs show up in practice.

Latency. Every tool call is now a network hop, or at least a process boundary, with serialisation on both sides. For a chatty agent that makes twenty tool calls per task, that adds up. Measure it. Batch where the server allows it.

Operational surface. A hosted MCP server is a service. It needs deployment, monitoring, versioning, and an on-call owner. A function in your codebase needed none of that.

Discovery drift. Because clients discover tools at runtime, a server can change its tools underneath a running agent. That is a feature during development and a hazard in production. Pin server versions in production and treat a tool schema change like an API change.

An MCP server is an execution boundary between a language model and real systems. Treat it like one.

• Least privilege per server. A server that reads the CRM should have a read-only credential. A server that can write should be a separate server with its own audit trail, not a flag on the read server.
• Validate inside the server. The JSON Schema protects you from malformed arguments, not from malicious ones. A file tool must refuse paths outside its allowed root. A SQL tool must not accept raw SQL from the model unless that is a deliberate, sandboxed decision.
• Treat tool output as untrusted. Data returned by a tool can contain instructions aimed at the model. A web-fetch tool that returns a page saying "ignore your previous instructions" is the standard prompt-injection vector. Filter, label, or isolate tool output before it reaches the model.
• Authenticate the client on HTTP servers. A remote MCP server with no authentication is an open API to your internal systems. Use the OAuth flow the specification describes, or at minimum a bearer token bound to a client identity.
• Log every call. Tool name, arguments, caller identity, result size, latency. This is your audit trail when someone asks what the agent did on Tuesday.

For the broader guardrail model this sits inside, see Enterprise AI Guardrails.

The rule of thumb: wrap a tool in MCP the day a second consumer appears, not before.

A server needs four things: a name and version, a list of tool definitions with schemas, a handler that executes each tool, and a transport. In the official SDKs that is a few dozen lines. The parts that take real time are the descriptions, the input validation, and the permission model, none of which the protocol can write for you.

The MCP chapter walks through a complete server and client in the agentic workflows series.

Is MCP tied to one model vendor? No. It was published as an open specification and has clients and servers across multiple model providers, IDEs and frameworks. The model never sees the protocol; the client translates.

Does MCP replace function calling? No. Function calling is how a model asks for a tool. MCP is how an application finds and runs tools. A client uses both: MCP to discover and execute, function calling to let the model choose.

Can an MCP server call another MCP server? Yes. A server can itself be a client of other servers. This is how aggregation and gateway servers work. Be careful with latency and with permission chaining.

How do I version a tool? The protocol does not version individual tools. Version the server, pin it in production clients, and treat a schema change as a breaking change with a new tool name if old clients still exist.

Is stdio safe in production? Stdio runs the server with the launching user's permissions on the same machine. It is fine for developer tooling. For shared or production use, run an HTTP server with authentication and its own credentials.

What are the three MCP primitives? Tools are functions the model can call, resources are read-only data identified by a URI that the application loads into context, and prompts are reusable templates the server offers to the client.

What does MCP cost me in practice? Three things: latency from an extra network hop or process boundary on every tool call, the operational surface of running a hosted server, and discovery drift when a server changes its tools under a running agent. Pin server versions in production.

How do I secure an MCP server? Use a least-privilege credential per server, validate arguments inside the server, treat tool output as untrusted, authenticate the client on HTTP servers and log every call with tool name, arguments, caller identity, result size and latency.

• MCP chapter
• Agent System architecture
• MCP topic hub
• AI Agent Loops: Stopping Conditions and Guardrails
• The Enterprise AI Engineering Blueprint (where MCP fits in the enterprise stack)
• Enterprise AI Guardrails (securing MCP servers with least-privilege access)