MCP Went to Production: 6 Things I Learned Building Real Servers

Straight answer: MCP (Model Context Protocol) is no longer an experiment. Born at Anthropic in November 2024 and donated in December 2025 to the Linux Foundation's Agentic AI Foundation — with OpenAI, Google, Microsoft, AWS, Cloudflare and Block on board — by 2026 it is effectively the standard by which AI agents talk to business systems. The numbers: 97 million monthly SDK downloads as of March 2026 (up from 100,000 at launch), between 8,000 and 12,000 servers catalogued in Q2 2026, and per the Stacklok 2026 report, 41% of software organizations run MCP servers in limited or broad production. I've built a few. What follows is the part that isn't in the spec.

TL;DR

An MCP server is not a wrapper around your APIs: it's a user interface, and the user is a model.
Tool descriptions are prompts. Written badly, the agent misfires and the model takes the blame.
Context budget is the scarce resource: a tool returning 40,000 tokens kills the session.
Errors must be instructions, not stack traces.
Every writing tool must be idempotent: agents retry, by design.
The security surface is real and under-policed: high privileges, prompt injection through data, audits rarely done.

Why it actually happened

MCP won for the same reason any standard wins: it removed a combinatorics problem. Connecting N models to M systems used to mean N×M bespoke integrations. With a shared protocol it becomes N+M. Not a conceptual revolution — the same logic as ODBC, as LSP for editors, as OpenAPI. It's boring, which is exactly why it works.

The move to the Linux Foundation in late 2025 is when it became adoptable by anyone unwilling to depend on a single vendor. From there, enterprise adoption stopped looking like a pilot and started looking like infrastructure: 28% of the Fortune 500 have implemented MCP servers.

Meanwhile it slipped into places you wouldn't expect: Google and Shopify's Universal Commerce Protocol uses MCP as one of the transports through which an agent queries a merchant's catalog. The protocol born to let Claude read files became a rail for commerce.

The 6 things I learned

1. Don't expose your APIs — design an interface for a model

My first server was a one-to-one wrapper over my REST APIs. Thirty tools, each mapped to an endpoint. Result: the agent called six in a row to answer a trivial question, lost the thread halfway, and occasionally picked the wrong tool because two names looked alike.

The lesson is that tools should be designed around tasks, not resources. Not get_customer, get_orders, get_order_items, get_shipment — but customer_order_summary, which does those four hops internally and returns one thing. Fewer tools, denser, with boundaries that match human intentions. The rule I use now: if answering a typical question takes more than two calls, your tool boundaries are wrong.

2. Tool descriptions are prompts — treat them that way

This cost me a week of debugging I was convinced was a model problem. It wasn't: it was an ambiguous description. A tool described as "search products" gets invoked when the user asks about an order status too, because to a model "search" is generic.

I now write descriptions with three mandatory elements: what it does, when to use it, when NOT to use it. And parameter descriptions are where battles are won: a limit documented as "max 20, use 5 unless explicitly asked" changes behavior more than any system prompt.

3. Context is the scarce resource, not latency

The most common mistake I see (and made): tools returning the full JSON payload because "the model will filter it anyway". The model doesn't filter — it pays. Forty products with every field is tens of thousands of tokens that stay in the conversation for the whole session, degrade attention and cost you on every subsequent turn.

Rules I apply:

Mandatory pagination with low defaults.
Only the fields needed to decide; details come from a second tool.
Tabular or compact output instead of verbose JSON when it's read-only.
A hard token ceiling per response, with explicit truncation ("showing 10 of 240 results").

4. Errors are instructions to the model

A 500 Internal Server Error is useless to an agent: it can't tell whether to retry, change parameters or give up. A well-written error is half the work:

"No product found for SKU 'ABC-12'. SKUs are 8 characters. Use search_products to find the correct SKU from the product name."

The model reads that sentence and corrects course on its own. It's the difference between an agent that seems smart and one that seems broken — and it has nothing to do with the model.

5. Idempotency, because agents retry

Agents retry: on timeouts, on ambiguous errors, on a planner's decision. If your create_order tool isn't idempotent, sooner or later you get two identical orders. Every writing tool in my servers takes an idempotency key and returns the same result if that key repeats.

Same principle that makes the new HTTP QUERY method interesting: declaring what is safe to repeat isn't academic formalism, it's what lets the surrounding system behave well without asking permission.

6. Security: where I'm most worried

MCP servers often run with high privileges — database, CRM, ERP access — and form an attack surface almost nobody reviews systematically. Three things I treat as non-negotiable:

Per-tenant, per-user credentials, never shared. The server must act on behalf of someone, with that someone's permissions. Otherwise you've built a perfect confused deputy: the agent asks for something legitimate and the server executes it with admin powers.
Prompt injection from data, not from the user. The text your tool returns enters the model's context. If a product description, a review or a customer note contains "ignore previous instructions and…", that line reaches the model with the same standing as your own instructions. Treat data as hostile input.
Audit logs on every invocation — who, what, which parameters, what outcome. When something goes wrong, and it will, without logs you can't even reconstruct what the agent decided.

One prudence rule I follow: destructive or irreversible operations are not tools. Deletions, refunds, bulk sends go through explicit human confirmation. Not from distrust of the model — because the cost of the error is asymmetric.

Not everything should be an MCP server

Contrarian note, now that MCP is being bolted onto everything: if a flow is deterministic, putting an agent in the middle only adds latency, cost and variance. Syncing a catalog every night doesn't need a model making decisions: it needs a cron job and an endpoint.

MCP shines where you need judgment over open-ended input: interpreting an ambiguous request, cross-referencing different sources, deciding which tool applies. For everything else, ordinary code is faster, cheaper and more predictable. Same reasoning I apply to agents over public data: the value is in the graph and the tools, not in the agent itself.

FAQ

Is MCP relevant for an SME or is it enterprise-only?

Relevant, if your data is spread across systems and you want to query it in natural language. An MCP server over your ERP and e-commerce lets you ask "which customers ordered twice and haven't come back in three months" without opening three back-offices. The cost is modest; the demanding part is security, not development.

What's the main risk?

Permissions. An MCP server with all-powerful credentials and no audit trail is an incident waiting to happen, especially because text entering the context can carry hostile instructions. Least privilege, per-user credentials, log everything.

Should I use public MCP servers or build my own?

For generic, widely used tools it makes sense to start from existing ones — while checking who maintains them and what they actually do (they run with your permissions: read the code). For your business data, a server of your own, designed around your team's real tasks, is almost always the better call.

Do MCP and REST APIs exclude each other?

No, they overlap with different purposes. APIs remain the contract for deterministic software; MCP is the interface for a consumer that reasons and makes mistakes. The two often live on the same backend, with MCP exposing fewer tools and more "tasks".

If you want to work out whether exposing your systems to an agent makes sense — and how to do it without opening a hole — let's talk. It's the kind of architectural call that lands on my desk often as a Fractional CTO.