Every six months or so, something lands in the AI tooling space that quietly changes how everyone builds. Model Context Protocol — MCP — is one of those things. If you've been ignoring it, you're already behind. If you've heard the name but haven't dug in, this is your briefing.
MCP is not hype. It's a specification that solves a real, painful problem: how do you give an AI model clean, standardized access to tools, data sources, and external systems — without writing bespoke glue code every single time? That problem has burned hundreds of engineering hours across every team building serious AI products. MCP is the answer the ecosystem has been fumbling toward for two years.
What Is Model Context Protocol?
Model Context Protocol is an open standard, originally developed by Anthropic, that defines how AI models communicate with external tools and data providers. Think of it as the USB-C of AI integrations: one protocol, many devices.
Before MCP, every AI integration was a snowflake. You'd write custom function definitions for OpenAI's tool-calling format, then rewrite them for Claude, then again for whatever local model your team wanted to experiment with. The tools themselves — your database connector, your file reader, your API wrapper — had no standard interface. Every model spoke a different dialect.
MCP changes the relationship between three actors:
- MCP Hosts — the AI application or agent runtime (Claude Desktop, your custom agent, an IDE plugin)
- MCP Clients — components inside the host that maintain connections to servers
- MCP Servers — lightweight processes that expose tools, resources, and prompts through the standard protocol
The model talks to the host. The host uses MCP clients to talk to servers. The servers do the actual work — querying your database, reading files, calling APIs. Clean separation of concerns. Finally.
The Protocol Primitives You Need to Understand
MCP defines three core primitives. Get these right and the rest follows naturally.
Tools
Tools are executable functions the model can invoke. They map closely to what you already know from OpenAI function calling or LangChain tools, but they live on the server and are discoverable at runtime. The model doesn't need to know about them at build time — it discovers what's available when the session starts.
// Example MCP tool definition (server-side, TypeScript SDK)
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";
const server = new McpServer({
name: "database-tools",
version: "1.0.0",
});
server.tool(
"query_customers",
"Query the customer database by email or ID",
{
identifier: z.string().describe("Customer email or numeric ID"),
limit: z.number().optional().default(10),
},
async ({ identifier, limit }) => {
const results = await db.customers.find({ identifier, limit });
return {
content: [
{
type: "text",
text: JSON.stringify(results, null, 2),
},
],
};
}
);Resources
Resources are read-only data the model can pull into context — files, database records, API responses, live system state. Unlike tools (which trigger actions), resources are about information retrieval. The host decides which resources to surface; the model decides which to read.
// Exposing a resource: current system metrics
server.resource(
"system_metrics",
"metrics://current",
async (uri) => {
const metrics = await getSystemMetrics();
return {
contents: [
{
uri: uri.href,
mimeType: "application/json",
text: JSON.stringify(metrics),
},
],
};
}
);Prompts
Prompts are reusable, parameterized prompt templates that servers can expose. This is underused but powerful — it lets you version and centralize the prompts your tools rely on, rather than scattering them across agent code.
Why MCP Matters for Production AI
If you've been building AI agents you plan to run in production, you've already felt the pain MCP addresses. Here's where it actually changes the game:
Portability Across Models
Write your MCP server once. It works with any MCP-compatible host — Claude, GPT-4 via a compatible wrapper, open-source models running locally. You're no longer coupled to a single provider's tool-calling spec. When a better model ships, you swap the host, not your entire integration layer.
Composability
A single MCP client can connect to multiple servers simultaneously. Your agent can pull from a filesystem server, a database server, and a third-party API server at the same time — all through one consistent interface. This is exactly the kind of infrastructure composability serious agent deployments need.
Security Boundaries
MCP servers run as separate processes. You can sandbox them, apply different permissions, run them in isolated environments. The model never has direct access to your infrastructure — it always goes through the server abstraction. For teams serious about production safety, this is a meaningful architectural win.
Discoverability
The model queries available tools at session start. This means your agent adapts to what's actually available rather than assuming a fixed set of capabilities. Deploy a new MCP server to your environment, and any connected agent automatically gains access to its tools. No code changes, no redeployment of the agent itself.
Transport Layer: How Clients and Servers Actually Connect
MCP supports two transport mechanisms, and choosing the right one matters for your architecture.
stdio transport is the default for local deployments. The host spawns the server as a subprocess and communicates over standard input/output. Simple, low-overhead, no networking required. This is what Claude Desktop uses for local MCP servers.
HTTP with SSE (Server-Sent Events) is for remote servers. The client sends requests over HTTP POST; the server streams responses back via SSE. This is what you want for production deployments where the MCP server is a separate service — or when you're building the kind of streaming, real-time integrations that modern AI apps demand.
# Running an MCP server over HTTP (Python SDK)
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("analytics-server")
@mcp.tool()
def get_daily_revenue(date: str) -> dict:
"""Fetch revenue metrics for a specific date (YYYY-MM-DD)"""
data = analytics_db.query_revenue(date)
return {
"date": date,
"total": data.total,
"transactions": data.count,
"average_order": data.average,
}
# Run with: mcp run server.py --transport sse --port 8080
if __name__ == "__main__":
mcp.run(transport="sse")Building Your First MCP Server: The Mental Model
Stop thinking about MCP servers as infrastructure. Think of them as capability packages. Each server wraps a coherent domain of functionality — your CRM data, your internal APIs, your file system, your deployment toolchain.
A few principles that save you pain:
One domain per server. Don't build a mega-server with 40 tools. Build five focused servers with eight tools each. Discovery works better, testing is easier, and you can version and deploy them independently.
Return structured data, not prose. Your tools should return clean JSON or structured text. Let the model decide how to present it. If you bake formatting into tool responses, you lose flexibility.
Handle errors explicitly. MCP has a defined error response format. Use it. Don't let exceptions bubble up as unstructured text — the model can't recover from those gracefully.
// Proper error handling in an MCP tool
server.tool(
"fetch_order",
"Retrieve order details by order ID",
{ order_id: z.string() },
async ({ order_id }) => {
try {
const order = await ordersApi.get(order_id);
if (!order) {
return {
content: [{ type: "text", text: `Order ${order_id} not found` }],
isError: true,
};
}
return {
content: [{ type: "text", text: JSON.stringify(order) }],
};
} catch (err) {
return {
content: [{ type: "text", text: `Failed to fetch order: ${err.message}` }],
isError: true,
};
}
}
);The Ecosystem Right Now
MCP adoption has accelerated faster than most open standards do. As of mid-2026, the following support it natively or through thin wrappers:
- Claude Desktop and Claude API — first-class support, reference implementation
- Cursor and Windsurf — MCP is how these IDEs extend their AI capabilities
- OpenAI's Responses API — added MCP-compatible remote tool calling
- LangChain and LangGraph — MCP tool adapters available (relevant if you're comparing those frameworks)
- Dozens of pre-built servers — for GitHub, Slack, PostgreSQL, filesystem access, browser automation, and more
This is what a maturing standard looks like. The tooling isn't perfect — the SSE transport has rough edges, the Python SDK is slightly behind the TypeScript one, and auth is still being standardized. But the trajectory is clear.
What to Build Next
If you're already building AI agents or tool-augmented LLM applications, the migration path is straightforward: take your existing tool definitions and wrap them in MCP servers. You don't have to do it all at once — MCP clients can coexist with native tool calling during a transition.
If you're starting fresh, build MCP-native from day one. You'll thank yourself when you want to swap models, add a new host interface, or hand off a server to another team.
The teams that win at AI tooling in the next two years won't be the ones who wrote the most clever prompts. They'll be the ones who built clean, composable tool infrastructure that any model can use. MCP is how you do that.
Practical Takeaways
- Start with the official SDKs — TypeScript and Python are both solid. Don't roll your own MCP implementation.
- Use stdio for local dev, SSE for production — the transport choice should follow your deployment model, not your preference.
- One domain per server — resist the urge to build monolithic MCP servers. Small, focused, independently deployable.
- Test your tools in Claude Desktop first — it's the fastest way to iterate on MCP server behavior without building a full agent harness.
- Return structured errors — models handle explicit isError responses far better than exception stack traces.
- Watch the auth spec — OAuth support is in progress and will matter the moment you're connecting to third-party services at scale.
MCP is the plumbing that makes serious AI tooling possible. Get comfortable with it now, because in twelve months it'll be table stakes.