MCPX: From Local Experimentation to Production-Grade Infrastructure

At Lunar.dev, we build infrastructure and middleware designed to support external connectivity at scale, from AI gateways to traffic orchestration layers. So when Model Context Protocol (MCP) began gaining traction as a flexible abstraction for tool-based API interaction, it was natural for us to explore how to bridge it with production-grade engineering principles.

What started as an internal experiment quickly evolved into a broader architectural challenge: how do we take a local-first protocol like MCP and make it operationally robust, secure, and usable across multiple teams and services?

This exploration led to MCPX. Our centralized, remote-ready gateway for aggregating and managing MCP servers. It's now available as open source: github.com/TheLunarCompany/lunar/tree/main/mcpx

This post is the first in a two-part series. Here, we’ll walk through our journey from a simple local MCP integration to a remote, production-ready MCPX deployment. In the second post, we’ll discuss the policy engine, integration with the Lunar AI Gateway, and strategies for governing agentic behavior in production.

Why MCP?

The Model Context Protocol (MCP) introduces a novel abstraction for consuming APIs through straightforward tool declarations. It enables agents to query for available tools (listTools) and call them based on context interpreted by an LLM, removing much of the traditional glue logic between client code and API services.

If you're new to MCP, we recommend reviewing this introduction for background on how the protocol works and the emerging ecosystem around it.

MCP’s Operational Gaps

While powerful in concept, MCP posed several limitations for real-world deployment:

1. Self-hosted silos. MCP is currently meant to run locally, often as an isolated server. This leads to decentralization  and fragmented infrastructure.
2. Lack of production maturity. Demos and internal tooling highlight its strengths, but MCP lacks core operational capabilities such as: scaling, rollout strategies, back-pressure, observability and more, which are essential for production workloads.
3. Weak security model. MCP offers no built-in scope or identity management. Any client can call any tool, with no way to isolate access by team, environment, or use case.

Addressing these gaps—shared infrastructure, hardened operations, and scoped access—became our north star for MCPX.

Phase 1: Local Experimentation

We began with a single-agent setup: the application connected to an MCP server on one side and an LLM (e.g., Gemini) on the other.

Example: An agent prompt
‍

The LLM processed the prompt and selected a suitable tool from the MCP server (e.g., Google Maps). This query-response loop yielded a result like:

The local setup was effective, but inherently non-scalable. Each new integration (e.g., Slack, Notion) required spinning up another MCP server manually.

Phase 2: Configurable Expansion via Claude Desktop Convention

To avoid duplicating logic and code, we adopted the Claude Desktop convention: each MCP integration could be launched from a config file, dynamically spawning MCP servers.

{
  "mcpServers": {
    "google-maps": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-google-maps"]
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_TEAM_ID": "TXXXXXXXXX2",
        "SLACK_CHANNEL_IDS": "CXXXXXXXXXC"
      }
    }
  }
}

‍


This eliminated the need for application changes when introducing new tools. Config alone determined what was exposed to the LLM. While effective for development, this still required running a local orchestration layer per service or developer.

Phase 3: Toward Centralization – Introducing MCPX

To scale usage across teams and simplify deployment, we developed MCPX. A shared, centralized gateway that aggregates tool declarations from multiple MCP servers into a single interface.

MCPX enabled:

• ✅ A single point of integration for all client agents
• ✅ Central management of tools from different domains
• ✅ Better onboarding and reduced duplication across teams

However, this centralization surfaced new challenges:

• ⚠️ Failure isolation: A failure in the MCPX process could affect multiple clients or use cases
• ⚠️ Access control: Without any built-in scoping, every agent could call every tool

We knew we’d need to address these risks in the next iteration. But first, we had to get the infrastructure right.

Phase 4: Making It Production-Ready — Remote, Resilient, and Scalable

To move from prototype to production, we containerized MCPX and deployed it in Kubernetes. This shift enabled a range of operational capabilities:

• ✅ Shared usage across teams: MCPX runs as a central internal service accessible to any authorized workload, eliminating per-team setup.
• ✅ Unified observability: Logs and metrics are aggregated, enabling visibility into tool usage patterns, error rates, and performance across all integrations.
• ✅ Zero-downtime deployments: Thanks to Kubernetes, rolling upgrades and self-healing behavior with minimal operational overhead is supported out-of-the-box.
• ✅ Environment promotion via CI/CD: The same container and configuration move cleanly across dev, staging, and production, ensuring reproducibility.
• ✅ HTTP-native communication: Standardized over HTTP, retries, and service meshes—unlocking production-level compatibility.

With this foundation in place, we were ready to move beyond infrastructure and address policy and access control, topics we’ll cover in part two.

What’s Next

Our journey from isolated local agents to a centralized MCP gateway required rethinking how MCP fits into modern infrastructure. MCPX represents our answer, modular, observable, scalable and it’s just the beginning.

In the next post, we’ll cover:

• The ACL (access control list) model we introduced to restrict tool usage per client
• Emerging thoughts on secure, multi-tenant AI agent platforms

We're also extending MCPX to connect with our Lunar AI Gateway—enabling runtime enforcement of policies and deeper control over agent behavior. This integration marks a key step in our broader roadmap to provide governance and observability for agentic systems at scale.

We're open-sourcing what we built, and we’d love your feedback or contributions:

➡️ github.com/TheLunarCompany/lunar/tree/main/mcpx

‍

‍