MCP moves into production: gateway trade-offs and lessons from a real Django server

MCP grows up in the field

Two dev.to write-ups published the same day capture the same shift from opposite directions: the Model Context Protocol is leaving the demo stage and entering production engineering. One post argues that teams running Anthropic's Claude Code across an organisation need a gateway between the agent and its MCP servers; the other collects the practical lessons a development team drew from months of building MCP servers for client Django applications.

The case for a gateway in front of Claude Code

According to the gateway-focused dev.to post, a few direct connections from Claude Code to MCP servers work fine during early development, but three problems appear at organisational scale.

The first is context cost. Every MCP server publishes JSON schemas for its tools, and clients load all of them into the prompt at the start of each turn. Five servers exposing 15 to 20 tools each push 75 to 100 schemas into context before the model has read a line of project code; at 150 to 300 tokens per schema, tool definitions alone consume 15,000 to 30,000 tokens per request, repeated across every step of a multi-step coding loop.

The second is credentials. GitHub tokens, database connection strings and internal API keys end up in plaintext configuration files such as ~/.claude. or .mcp. on developer machines, and tools that ingest untrusted web content create a prompt-injection path toward destructive database actions.

The third is auditability. Compliance regimes like SOC 2, ISO 27001 and HIPAA expect traceable records of automated actions, and logs scattered across terminal sessions and individual server processes cannot provide them.

What the comparison recommends

The post evaluates gateways on aggregation of stdio, SSE and HTTP servers into a single connection; token optimisation through filtering or on-demand loading; authentication with virtual keys and budgets; routing overhead; multi-provider model routing; and guardrails such as secrets detection and PII masking.

Its top pick is Bifrost, an open-source gateway written in Go by Maxim AI, credited with sub-millisecond routing overhead and a Code Mode execution approach said to cut tool-definition token costs by up to 92.8 percent. Docker MCP Gateway is positioned for container isolation, IBM ContextForge for multi-protocol federation, and LiteLLM for Python-based proxying. These rankings are the author's assessment rather than published benchmarks, and the post itself champions Bifrost, so teams should treat the ordering as a starting point rather than a verdict.

Lessons from shipping a Django MCP server

The second post, from a team that has spent months building MCP servers for client Django applications, starts by trimming expectations: MCP standardises how tools, resources and prompts are exposed over JSON-RPC via stdio or HTTP/SSE, but it supplies no authentication, access control, rate limiting or business logic. The protocol is transport; everything operational sits above it.

Their server runs as a standalone Python process that imports Django models and services rather than living inside a Django view, and several lessons stand out.

Tool descriptions are the real prompt engineering surface. A description stating when to call a tool, what inputs it expects and what it returns does more for reliability than the code behind it, and deserves the same care as a system prompt.

Every exposed tool is an action an agent can take. The team shipped a send_email tool too early, and the agent used it in a context nobody anticipated: emailing a customer a summary before the underlying data was complete, which produced a support ticket. The fix was a dry_run parameter plus a required confirmation before the live call, not removing the tool.

Write tool calls should be logged before execution in a durable record capturing tool name, arguments, result and caller, so that failed or crashed calls still leave a trace.

The async MCP SDK also collides with Django's synchronous ORM: direct queries raise SynchronousOnlyOperation errors, so ORM work must be wrapped with sync_to_async. The DJANGO_ALLOW_ASYNC_UNSAFE setting helps surface problems during development but, as the post warns, must never reach production. Stdio transport suits local desktop clients; networked production agents should use HTTP/SSE instead.

Why it matters

Both posts converge on the same conclusion from opposite ends of the wire: MCP solves interoperability, not operations. Token budgets, credential handling, audit trails and the blast radius of write-capable tools remain the adopter's problem, whether you front many servers with a gateway or build a single server carefully. As coding agents gain write access to real business systems, that operational layer, not the protocol itself, is where production readiness will be decided.