cfdocs__*
Cloudflare's public docs MCP server — a real third-party upstream, governed and namespaced like any internal one.
v1.10.1Apache-2.040/40 MCP conformant
The enterprise MCP gateway.
One governed endpoint between every MCP (Model Context Protocol) client and every MCP server. Federation, auth, policy, tenancy, budgets, and audit, built on the official MCP Go SDK on both sides of the proxy.
See it live.
demo.fold.run federates three public MCP servers behind one endpoint: the unmodified release binary, governed by its own config. Rate-limited, unauthenticated, no warranty. Copy-paste walkthrough: try the demo.
The console ships inside the binary and needs no client. Open it and you are reading the running federation: a row per upstream carrying its breaker, whether it is connected and its live latency. Its test console calls the same endpoint everything else does. The topology at the top of this page is drawn by hand; the console draws its own from the federation it is serving, each route labelled with the latency it is answering in.
git__*
GitMCP — a public upstream two revisions behind the rest. Behind the gateway it is just another namespace.
jobs__*
A task-minting demo server. Start a job, then poll it with nothing but the task id — fold routes every poll to the owner.
The same three upstreams, governed.
enterprise.fold.run runs the same binary over the same federation, with auth required and two tenants on it. acme spends up to 5,000 upstream calls a day at 120 req/min; globex gets 1,000 at 60, and never reaches GitMCP at all — the subset filters the fan-out before policy runs, so that upstream is not asked, not billed, and not a partial failure when it is down. Policy is deny-by-default and splits each tenant by whether the caller is a person or an agent.
Run it in 60 seconds.
fold is a single static binary with no local state. One config file in front of your first server, governance when you're ready.
Describe your upstreams
fold.config.json{ "upstreams": [ { "id": "github-tools", "url": "https://mcp.platform.acme.com/mcp", "namespace": "gh", "owner": { "org": "acme-platform", "team": "devex" } } ] }Run it
shell# one upstream, one governed endpoint — 60 seconds $ go run github.com/fold-run/fold/cmd/fold@latest --config fold.config.json # or the container: $ docker run -p 8080:8080 -e FOLD_CONFIG="$(cat fold.config.json)" ghcr.io/fold-run/foldPoint a client at it
Any MCP client connects to /mcp and sees one virtual server named fold with every team's tools. MCP endpoint: http://localhost:8080/mcp · health: /health · metrics: /metrics
Binary
A single static Go binary — go install, or grab a prebuilt archive from GitHub releases. Linux and macOS, amd64 and arm64.go install github.com/fold-run/fold/cmd/fold@latest
Container
Multi-arch and distroless, ~22 MB. Config injected as a file or straight through FOLD_CONFIG.ghcr.io/fold-run/fold
Kubernetes
A Helm chart with probes, HPA, and ServiceMonitor — plus fold-discovery, so labeled Services join the federation on their own.
One gateway.
A family of problems.
Most deployments start with one of these and grow into the others — they all ride the same config file.
- Federate
Unify a federation
Acquisitions, child orgs, and teams each ship their own MCP servers — any language, any SDK. fold presents them as one virtual server with namespaced tools. No team rewrites anything.
Discover upstreams automatically
A team ships an MCP server, the registry lists it, and it appears behind the gateway — no config change. On Kubernetes, label a Service fold.run/upstream: "true" and fold-discovery does the rest.
Run tasks across the federation
Long-running work flows through fold: task polls and updates route to the server that owns the task — remembered at mint, or found by probe — and tasks/list merges every org, scoped per principal.
Federate local servers
Most MCP servers are local processes speaking stdio, not HTTP endpoints. The fold-stdio shim runs one and serves it over HTTP, so it joins the federation as an ordinary upstream with every policy and guard applied unchanged.
- Govern
Draw the security boundary
One choke point for authentication, deny-by-default tool allowlists, per-principal visibility, and an audit event for every request — including the denials.
Govern each customer separately
A tenant is a named set of principals carrying its own allowance, its own rate-limit bucket, and its own view of the federation. Ten agents on one team share one bucket rather than holding ten between them.
Broker credentials
Clients hold one token with fold as audience; fold exchanges it per upstream (RFC 8693) or injects service credentials. API keys never reach agents.
Govern vendor MCP servers
Put third-party and SaaS MCP endpoints behind your own auth, policy, and audit — instead of scattering per-user API keys across every client.
- Operate
Protect fragile services
List caching, global and per-upstream rate limits, and circuit breakers stand between agent traffic storms and your internal systems.
Expose tools outward, carefully
Offer partners a curated, policy-scoped subset of internal tools on one hardened endpoint — a single static binary, self-hosted in your VPC.
Bound what a period can cost
Rate limits smooth a burst and then forget it. Budgets accumulate across an hour, a day, or a month, charged in upstream invocations rather than client requests, so a busy month meets a ceiling instead of an invoice.
Conformant, provably
The official MCP conformance suite runs through fold on every merge — 40/40 checks, including sampling, elicitation, and subscriptions bridged through the gateway.
Start where it hurts.
A single passthrough upstream in front of your most-used server is one config file away. Governance grows from there.
Get started