Getting an MCP server running in a dev environment is straightforward. Getting it to survive real usage - real agents, real data, real traffic - is where most teams learn hard lessons.
Here's what separates demos from production.
1. Scoped, revocable auth on every tool call
Every request to your MCP server should carry a credential, and that credential should be verified before any tool executes. The server should know which agent is calling, on behalf of whom, and what it's allowed to do.
This means:
- API keys or OAuth tokens on every request, not a single shared secret
- Tool-level permission scopes - a reporting agent can call
get_revenue_databut notdelete_record - Revocability - you can cut off a misbehaving agent without taking down everything else
If your server currently trusts any caller that hits the right endpoint, you've built a demo, not a production system.
2. Structured error responses the agent can reason about
Agents don't crash when they get an error - they try to handle it. If your error responses are unstructured strings or raw stack traces, the agent has nothing to work with and will either hallucinate a fix or loop endlessly.
MCP defines an error format. Use it. Return:
- A machine-readable error code (
RECORD_NOT_FOUND,PERMISSION_DENIED,RATE_LIMITED) - A human-readable message the agent can incorporate into its reasoning
- No internal details (stack traces, SQL queries, file paths) that could leak implementation information
Structure your errors like you're designing an API - because you are.
3. Observability on every tool invocation
In production, you need to know what your agents are doing. Not just that a tool was called - but which agent called it, with what arguments, what it returned, and how long it took.
At minimum, log:
- Tool name and input arguments (sanitised - redact PII before logging)
- Agent identifier
- Response status and output size
- Latency
At best, route these into your existing observability stack (Datadog, Grafana, whatever you use). Tool call traces are the single most useful debugging surface when an agent does something unexpected. Without them, you're guessing.
4. Tight input validation and output sanitisation
Your MCP server is a new attack surface. Agents can be manipulated into sending malformed inputs, and your server shouldn't propagate those errors into your downstream systems.
Validate every input against its schema before execution. Reject tool calls with missing or malformed arguments immediately, with a clean error, before touching any data. On output, sanitise anything that returns user-generated content before it goes back to the agent - you don't want prompt injection living in your database to flow back into the model's context.
This is basic, and it's often skipped in the prototype phase. Don't skip it.
5. Rate limiting per agent and per tool
Without rate limiting, a single misconfigured or runaway agent can exhaust your downstream APIs, saturate your database, or just generate a surprisingly large bill.
Apply rate limits at two levels:
- Per-agent - how many requests can a single agent make per minute?
- Per-tool - expensive operations (full-text search, external API calls, complex aggregations) should have lower limits than cheap ones
Implement these at the MCP server level, not just at the downstream system. You want the agent to get a clean RATE_LIMITED error with a retry-after header, not a timeout from an overloaded database.
The common thread
Every item on this list is table stakes for any production API. The reason teams skip them on MCP servers is that the prototype phase is so fast - you can have something working in a day - and it's tempting to call it done.
Don't. An MCP server is infrastructure that agents will depend on. Treat it accordingly.
If you'd rather have this done right than done quickly and fixed later, we build production-grade MCP servers with all of this included from day one.