MCP Gateway Lessons from Production

MCP (Model Context Protocol) makes it easier for agents to call tools. A gateway sits between agents and those tools so you get one place for auth, routing, policy, and logs.

I run that pattern in production (MCPJungle in front of many services). The demos look tidy. Production is where the lessons are.

Lesson 1: Permissions beat prompts

If an agent can delete a repo, a clever system prompt will not save you forever.

Treat the gateway like an API edge:

• Least privilege per agent role (content vs ops vs finance)
• Separate credentials per downstream system
• Explicit allowlists of tools, not “all MCP servers enabled”
• A human-owned kill switch (disable a tool or an agent without redeploying everything)

Company OS thinking helps here: tools belong under guardrails, not under hope. See Company OS vs frameworks.

Lesson 2: Blast radius is a product decision

One mis-scoped write tool can touch CRM, git, and billing in a single agent turn.

Design for blast radius:

• Prefer read-only tools by default; promote writes deliberately
• Split “draft” tools from “publish/send” tools
• Put irreversible actions behind approval workflows outside the model

My rule of thumb: anything externally visible (email, publish, customer ticket reply) needs a human gate until the loop has weeks of clean telemetry.

Lesson 3: Timeouts and partial success are the real bugs

The failure mode that hurts most is not a clean 500. It is:

1. Agent calls tool A — succeeds
2. Tool B times out — agent retries or invents a workaround
3. Tool C never runs — agent reports “done”
4. Humans assume the job finished

Gateway requirements that demos skip:

• Hard timeouts per tool
• Idempotency keys where writes matter
• Structured error codes agents must handle
• “Incomplete” as a first-class status, not only success/fail

Lesson 4: Log the tool call, not just the chat

Chat transcripts are weak forensics. You need:

• Which agent, which tool, which args (redacted), which latency, which result class
• Correlation IDs across orchestration (n8n / jobs) and the gateway
• Alerts on error-rate spikes per tool, not only per agent

Without this, you cannot tell model failure from integration failure.

Lesson 5: Schema drift breaks agents quietly

MCP tool schemas change when someone updates a server. Agents keep calling yesterday’s shape. Symptoms: empty fields, wrong IDs, “successful” calls that no-op.

Operational habits:

• Version tool schemas
• Smoke-test critical tools on a schedule
• Fail closed when required fields disappear

Lesson 6: Cost and rate limits move upstream

Fifteen tools behind one gateway means one place to:

• Cap concurrent calls per agent
• Cache expensive reads
• Route heavy jobs to async workflows instead of synchronous tool spam

LiteLLM-style model gateways and MCP tool gateways solve related problems on different axes: tokens vs actions. You usually want both.

Minimal production checklist

Before calling an MCP gateway “live”:

• Per-agent tool allowlist
• Write tools gated or approval-backed
• Timeouts + incomplete status
• Redacted request/response logging
• On-call path when a tool error-rate spikes
• Documented owner for each connected system

Where this sits in the stack

MCP gateways are infrastructure for agentic engineering — not a substitute for orchestration or for an operating model. Full picture: /stack. Hire path if you are stuck on the production gap: /hire.