👋 Introduction
The hardest part of shipping a useful AI agent has never been the model. It is the integrations. Every CRM, ticketing system, internal database, and SaaS API speaks its own dialect. For two years, every team building agents has reinvented the same plumbing — auth flows, schema mapping, retry logic, response parsing — for every tool they wanted their agent to touch.
The Model Context Protocol (MCP) is the standard that finally puts a stop to it. Anthropic open-sourced the spec in late 2024, and by mid-2026 it has quietly become the default way serious teams wire agents into the real world. If you have been ignoring it, this is your nudge.
What MCP Actually Is
MCP is a small, well-specified protocol for how an LLM-powered client talks to external context providers. Think of it like the Language Server Protocol (LSP) that unified IDE tooling — except instead of "give me autocomplete for Python," it is "give me access to this Postgres database, this Linear workspace, this S3 bucket, and this internal service."
The protocol has three primitives:
- Resources — read-only context the model can pull (files, DB rows, search results)
- Tools — actions the model can invoke (send an email, run a query, create a ticket)
- Prompts — reusable templates the server exposes to the client
A server wraps one system (say, GitHub). A client is whatever runs the model (Claude Desktop, your custom app, an IDE). The model picks which servers to talk to and when.
Why It Matters Now
Three things changed in the last year:
- Every major model now speaks MCP natively. Claude, GPT, Gemini, and the leading open models all ship MCP-compatible clients or SDKs. You write the server once.
- The ecosystem hit critical mass. There are well-maintained servers for Postgres, GitHub, Slack, Linear, Notion, Stripe, Google Drive, Sentry, Snowflake — most of what a typical company actually uses.
- Enterprises got serious. OAuth flows, audit logging, and per-tool permissioning are now first-class in the spec. You can give an agent narrow access to a single Jira project without handing it the keys to your kingdom.
If you tried to build an agent in 2024 and gave up after the third custom adapter, MCP is the thing you have been waiting for.
A Concrete Architecture
Here is the shape of a production agent we recently shipped for an ops team. The agent answers questions like "which customers in the EU tier hit our rate limit yesterday and have an open Zendesk ticket?" — a query that cuts across three systems.
┌────────────────────────┐
│ Agent (Claude API) │
└────────────┬───────────┘
│ MCP
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ postgres │ │ zendesk │ │ datadog │
│ MCP │ │ MCP │ │ MCP │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
▼ ▼ ▼
┌─────┐ ┌─────┐ ┌──────┐
│ DB │ │ API │ │ logs │
└─────┘ └─────┘ └──────┘
Three MCP servers, each a focused wrapper. The agent decides at runtime which to call. We did not write any glue between them — the model orchestrates.
A Minimal MCP Server
Here is what an MCP server looks like in practice. This one exposes a single read-only tool over a Postgres analytics warehouse.
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
import { Pool } from "pg";
const pool = new Pool({ connectionString: process.env.DATABASE_URL });
const server = new McpServer({
name: "analytics-warehouse",
version: "1.0.0",
});
server.tool(
"run_readonly_query",
"Run a read-only SQL query against the analytics warehouse.",
{
sql: z.string().describe("A single SELECT statement. No DDL or DML."),
limit: z.number().int().min(1).max(1000).default(100),
},
async ({ sql, limit }) => {
if (!/^\s*select\b/i.test(sql)) {
throw new Error("Only SELECT queries are permitted.");
}
const result = await pool.query(`${sql} LIMIT ${limit}`);
return {
content: [{ type: "text", text: JSON.stringify(result.rows, null, 2) }],
};
}
);
const transport = new StdioServerTransport();
await server.connect(transport);That is the entire integration. No model-specific code. No prompt engineering. Any MCP-compatible agent can now query your warehouse — safely, with a typed schema and a hard SELECT-only guardrail.
Production Patterns That Actually Matter
Once you have a couple of MCP servers running, the architectural questions get more interesting. Here is what we have learned from running these at scale.
1. Treat servers as untrusted code, even your own
MCP servers run as separate processes. Sandbox them. If a server talks to your prod database, give it a read-only role with row-level security. The agent will, eventually, ask it to do something stupid. Your server should refuse, not the model.
2. Build narrow, composable servers — not god-servers
The temptation is to build one giant company_api server with 40 tools. Resist. Servers are cheap to spin up. A customers server, an invoices server, and a support server are easier to reason about, easier to permission, and easier to swap out independently.
3. Tool descriptions are prompts
The description field on a tool is what the model uses to decide whether to call it. Treat it like a prompt: clear, specific, and honest about edge cases. "Sends an email" is bad. "Sends a transactional email via SendGrid. Use only for system notifications, not marketing." is good.
4. Log every tool call
Every MCP call is an action your agent took on behalf of a user. Log the inputs, outputs, latency, and the user identity. This is your audit trail when something goes wrong — and something always goes wrong.
5. Add a human-in-the-loop tier for destructive actions
Read tools can be auto-approved. Write tools, especially anything irreversible, should require explicit user confirmation in the UI. MCP supports this via the client side — use it.
What MCP Does Not Solve
MCP is a connectivity standard, not a magic wand. It does not solve:
- Agent reliability. Models still hallucinate, still loop, still pick the wrong tool. You need evals.
- Cost. More tools = more decisions = more tokens. Audit your agent traces and prune the tools the model never uses well.
- Discovery. Agents do not always know which server to call for a given question. You may need a routing layer — sometimes another small fine-tuned model — to pick the right toolset.
- Long-running work. MCP is request/response. If your tool needs to run for an hour, you need a job queue and a "check status" tool, not a single long call.
Migration Tip: Start By Replacing Your Worst Adapter
If you already have an agent in production with hand-rolled integrations, do not rewrite everything. Pick the flakiest, most painful integration you maintain and replace just that one with an MCP server. You will get an immediate quality-of-life win, and you will learn the protocol on a problem that already had your full attention.
Conclusion
MCP is the boring, unsexy infrastructure win that the AI agent space needed. It is not going to make your agent smarter — but it will make it possible to actually ship one without a six-month integration engineering project.
If you are starting a new agent project today, build it on MCP. If you have an existing one held together with bespoke adapters, start migrating the worst ones. By the end of the year, anything that does not speak MCP will look as dated as a service that does not speak HTTP.
Need Help Wiring This Up?
We have built MCP servers across messy enterprise stacks — legacy ERPs, custom CRMs, internal warehouses — and the agents that use them in production. If you want to ship an agent that actually does the work instead of one that demos well, book a call.
Thanks for reading 😄.
