When teams started shipping MCP servers in late 2025, three patterns showed up immediately: every team rolled their own thin HTTP wrapper, every wrapper had a slightly different idea of what authentication meant, and almost no wrapper produced an audit trail you'd ever pass a SOC 2 review with.
The MCPs themselves were beautiful — a clean protocol for tool calls, prompts, resources, completions. The operational layer around them was a mess.
This is what MCPG is for.
What we tried first
Before writing MCPG, we tried four things, all of which failed for non-obvious reasons:
1. Use a generic API gateway. Kong, Tyk, Envoy. They route HTTP. They don't
understand MCP. You can't write a policy that says "deny tools/call when the tool
is database.drop_table and the caller's group isn't dba" because the gateway has
no idea what those words mean. You end up with a forest of regex on body payloads.
Fragile. Slow. Untestable.
2. Use a sidecar pattern. Run a small service next to each MCP server that does identity + policy. Sounds clean. Falls apart fast: you maintain N sidecars, your audit logs are scattered across N services, and policy changes require N redeploys. You also can't compose policy across MCPs — a "user can spend $X across all tools" budget is impossible if every tool has its own sidecar.
3. Roll your own wrapper. Five engineers, each shipping a thin Express / FastAPI / Axum wrapper around their team's MCP server. Six months in: five different opinions about session handling, three different audit log formats, zero ability to enforce a shared policy. We've all done this. It does not scale.
4. Use the LLM provider's built-in tool gating. Anthropic, OpenAI, and others ship some kind of "approved tool list" feature. These are good for the agent but useless for the operator. They don't audit. They don't rate-limit. They don't redact. They don't compose.
What MCPG actually does
MCPG is a Rust binary that sits between your MCP clients and your MCP tools. It:
- Speaks MCP natively — the gateway understands sessions, tool calls, prompts, resources, completions, notifications. Policy can reference any of them.
- Resolves identity per-request — OIDC, mTLS, SPIFFE, API keys. One canonical
Callerstruct flows through the rest of the pipeline. - Authorizes per-decision — Cedar, OPA, or Casbin. Compose them. Stack obligations and redactions.
- Audits every decision — tamper-evident chain with Ed25519 signatures, per-org.
- Limits per-everything — rate limits per identity, per tool, per session; circuit breakers per tool; response caches.
- Streams telemetry — Prometheus, OTLP, structured logs. Per-call samples to a control plane that aggregates fleet-wide.
It runs as a single binary, in Docker, on Kubernetes, or in your own cloud account. It works at any scale from one developer's laptop to a multi-region SaaS deployment.
Why a single binary
MCPG is one Rust binary. The control plane is another. Together they're under 60MB compressed. You can run them on a Raspberry Pi.
This is on purpose.
Modern infra is too often architected as "ten microservices in a happy path, twenty in the failure path". For an operational layer — something that has to work when everything else is on fire — that's the wrong shape. We chose Rust because it gives us a single statically-linked binary; we chose async-trait FFI because it gives us plugin extensibility without process boundaries; we chose SQLite as the default backend because it works on a laptop and scales further than people think.
For fleets, swap to Postgres. For HA, run three replicas with NATS. The same binary, the same config model, the same UX.
Why open source
The protocol layer of agent infrastructure should not be a proprietary toll booth.
Every plugin we ship is Apache-2.0. The gateway is Apache-2.0. The control plane is Apache-2.0. The Helm chart, the CLI, the dashboard, the Helm operator — Apache-2.0.
A small set of enterprise modules (SCIM provisioning, SAML adapter, approval-workflow engine, compliance-pack generator, tamper-evident audit-chain HSM signing) ship under BSL-1.1, with automatic conversion to Apache-2.0 three years from each release. Nothing already Apache-2.0 ever moves to a more restrictive license.
The cloud is the upsell. The code is the floor.
Where we are
MCPG is in public beta. The gateway runtime, 38 plugins, the control plane, and the Helm chart are running in production at design-partner orgs. The K8s operator and managed cloud are still pre-GA. We're targeting 1.0.0 GA in 2026.
If you're using MCP at any non-trivial scale, join the beta. Tell us what you actually need. The roadmap is open.