Why MCP, and why now
For two years, every serious agent stack rebuilt the same primitives: a tool registry, a prompt-side schema, a router, a broker for long-running jobs. MCP standardises that surface. Once you accept the protocol, your agents get portability across models, and your tools get reusability across agents.
The practical win is not the JSON envelope — it's the separation of concerns. A single MCP server can be consumed by a Claude-hosted assistant, an internal LangGraph agent and a nightly batch job, without three different adapters.
Server design: one capability, one server
The most common mistake teams make is packing every tool their organisation owns into a single MCP server. That server becomes a coupling point: schema changes break unrelated agents, auth is impossible to reason about, and the tool list grows past the point where the model can pick reliably.
Group tools by capability boundary — 'billing', 'search', 'crm-write' — and ship each as its own MCP server behind its own URL. Compose them at the client. Ten focused servers with five tools each beat one server with fifty tools every time.
- One capability per server — align with the team that owns the underlying system.
- Version the server URL (`/mcp/v1/billing`), not just the schema.
- Ship a `list_tools` response under 2KB — that text is in the model's context on every turn.
- Prefer resources over tools for read-only data — resources are cacheable and don't consume a turn.
Tool contracts the model can actually use
LLMs pick tools from their description. A tool called `run_query` with the description 'Runs a query' is a coin flip. A tool called `search_orders` with 'Search customer orders by email, order id or date range; returns up to 50 rows' is picked correctly nearly every time.
Write tool descriptions like you'd write a Stripe API doc: name the inputs, name the outputs, name the constraints. Then have a second engineer read only the descriptions and try to guess which one to call for a given task. If they can't, the model can't either.
{
"name": "search_orders",
"description": "Search customer orders. Filter by email, order_id or an ISO date range (inclusive). Returns up to 50 rows sorted by created_at desc.",
"inputSchema": {
"type": "object",
"properties": {
"email": { "type": "string", "format": "email" },
"order_id": { "type": "string", "pattern": "^ord_[a-z0-9]{16}$" },
"from": { "type": "string", "format": "date" },
"to": { "type": "string", "format": "date" }
},
"additionalProperties": false
}
}Authorization: the model is not your auth layer
Every production incident we've seen in MCP systems traces back to one assumption: 'the model won't call that tool unless the user asked for it.' It will. Prompt injection is real, and the whole point of an agent is that it decides.
Put a deterministic policy layer between the MCP server and the underlying system. The model's identity is never sufficient — carry the end user's identity through the call, and let the policy layer decide whether this user, on this resource, with this tool, is allowed.
- Bind every MCP session to a short-lived, user-scoped token — never a service credential.
- Enforce row-level access in the tool handler, not in the prompt.
- Require an explicit human-in-the-loop confirmation for anything destructive or irreversible.
- Rate-limit per user and per tool — a runaway agent should hit a wall, not your database.
Observability: one span per tool call
A production agent trace has three layers: the model call, the tool call, and the downstream system call. If you only trace the model, you'll spend weeks debugging 'the agent got it wrong' when the real bug is a 400ms timeout in the third-party API.
Emit an OpenTelemetry span for each tool invocation with the tool name, input hash, output size, latency, token cost and success flag. Sample 100% for the first month — you'll find at least three surprising loops before you're allowed to turn sampling down.
Cost control: resources, caching and turn budgets
The cost of an agent is dominated by two things: how many turns it takes, and how big the context is on each turn. MCP gives you a lever on both. Move read-heavy state into MCP resources so the model reads them once per session, not once per turn. And set a hard turn budget in the client — 8 turns for most workflows, 20 for the hairy ones, and a clean shutdown after that.
Rollout pattern that survives contact with users
Ship an MCP server behind an internal-only client first. Shadow-run it against a deterministic baseline for two weeks. Then expose it to a single agent for a single workflow. Only after that go multi-tenant. Every step of the ladder catches a different class of bug — skipping any of them is how you end up rewriting the protocol on a Friday night.
FAQ
- Is MCP production-ready?
- The protocol is stable enough to build on. The gaps in mid-2026 are around multi-tenant auth patterns and long-running job semantics — both solvable with a thin wrapper, neither a reason to wait.
- Do I need MCP if I already have a working LangChain / LlamaIndex agent?
- If your tools are only ever consumed by one agent runtime, no. If you want the same tool to be usable by a Claude desktop app, an internal orchestrator and a batch job, yes — MCP is the cheapest way to stop maintaining three adapters.
- How do I stop the model calling the wrong tool?
- Write better tool descriptions before you write more guardrails. Descriptions are the model's UI. If two tools sound similar, rename them. If a tool is dangerous, put it behind a confirmation prompt at the client layer, not a system-prompt warning.
Building something like this?
Simatech ships AI-native Scrum squads for teams doing exactly this work — MCP agents, GraphRAG, LLMOps and the rest.
Talk to us