ContextForge: AI Gateway for MCP, A2A & REST APIs
ContextForge is IBM's registry and proxy that federates MCP servers, A2A agents, and REST/gRPC APIs behind a single gateway endpoint. Reach for it once you're running several MCP servers and want centralized auth, discovery, and tracing instead of wiring each client separately; skip it if you only run one MCP server, since the mandatory secret setup and Postgres-backed stack are more than that scale needs.
What ContextForge Does
ContextForge is IBM's open source registry and proxy that federates MCP servers, A2A agents, and REST/gRPC APIs behind a single endpoint for AI clients. It runs as a fully MCP-compliant server itself, translating REST and gRPC services into MCP-style tools, prompts, and resources, with an Admin UI for managing what's registered. It deploys via PyPI, Docker, or a Helm chart for Kubernetes, with Redis-backed caching for multi-cluster setups.
Core Gateway Capabilities
- ✓Tools Gateway translates REST and gRPC services into MCP-compliant tools, including gRPC-to-MCP translation via automatic reflection-based service discovery, per the README.
- ✓Agent Gateway routes A2A (Agent-to-Agent) protocol traffic and supports OpenAI-compatible and Anthropic agent routing.
- ✓API Gateway layer adds rate limiting, authentication, retries, and a reverse proxy in front of plain REST services.
- ✓Unified registries cover prompts (Jinja2 templates with rollback/versioning), resources (URI-based access with MIME detection and SSE updates), and tools (with input validation and concurrency controls).
- ✓OpenTelemetry tracing ships with support for Phoenix, Jaeger, Zipkin, Tempo, DataDog, and New Relic as backends, plus LLM-specific metrics like token usage and cost, and the README says it adds zero overhead when disabled.
- ✓For transport flexibility, support is available for HTTP, JSON-RPC, WebSocket, SSE (featuring configurable keepalive), stdio, and streamable-HTTP. Users can also select which MCP protocol version (e.g. 2025-11-25) a given connection uses.
- ✓40+ plugins extend transports, protocols, and integrations, per the README.
- ✓The Admin UI, built on HTMX 2.0.3 and Alpine.js, gives a real-time log viewer with filtering, search, and export, plus support for airgapped deployments.
Managing AI Agents and Tools
- •Register an existing MCP server (or a REST/gRPC service wrapped via mcpgateway.translate) with the gateway's /gateways endpoint so every AI client hits one authenticated URL instead of connecting to each server directly.
- •Bundle several registered tools into a single 'virtual server' via the /servers endpoint, so an agent gets one MCP endpoint that fronts multiple underlying tool sources.
- •Route A2A traffic to OpenAI-compatible or Anthropic agents through the same gateway, per the README's Agent Gateway capability, instead of maintaining separate connection logic per agent framework.
- •Wrap a legacy REST API as an MCP-compliant tool automatically, with the gateway extracting the JSON Schema and handling headers, tokens, retries, and rate limits for you.
- •Trace tool and prompt calls across federated gateways with OpenTelemetry, forwarding to Phoenix, Jaeger, Zipkin, or another OTLP backend to see where a multi-agent call chain actually spends its time.
Installation and Deployment
ContextForge is published on PyPI as mcp-contextforge-gateway, so `pip install mcp-contextforge-gateway` (or the faster `uvx --from mcp-contextforge-gateway mcpgateway`) gets the package; Python 3.11 or later is required. Before it will start, you must generate real secrets with `python3 -m mcpgateway.scripts.init_secrets` — the README is explicit that JWT_SECRET_KEY and AUTH_ENCRYPTION_SECRET are required in every environment, including local development, and the gateway refuses to boot without them. For a full stack with PostgreSQL and Redis, clone the repo and run `docker compose up -d`; this pulls a pre-built image from GHCR rather than building locally, since a local build needs a hermetic wheel closure only produced by CI. Kubernetes deployment goes through a Helm chart in charts/mcp-stack, with enterprise features like HPA autoscaling and RBAC. One platform caveat from the README: arm64 isn't supported in production containers, so Apple Silicon users should run under Rosetta or install via PyPI instead.
Strengths
- ✓Actually federates three different worlds — MCP servers, A2A agents, and plain REST/gRPC APIs — behind one endpoint, rather than solving just one of them.
- ✓Observability isn't bolted on: OpenTelemetry tracing covers six backend options (Phoenix, Jaeger, Zipkin, Tempo, DataDog, New Relic) with LLM-specific metrics like token usage and cost.
- ✓Multiple deployment paths that scale with need — a single uvx command for local testing, Docker Compose for a full Postgres/Redis stack, and Helm for Kubernetes with autoscaling.
- ✓Security defaults are strict rather than permissive: secrets are mandatory even locally, and Helm's SSRF protection blocks private-network URLs unless you explicitly allow them.
- ✓The README cites 7,000+ tests plus pre-commit hooks and live reload, a real signal of engineering discipline for a project at this scale.
Considerations and Current Limitations
- △Getting a local instance running takes more than a couple of commands: you must generate and export JWT_SECRET_KEY and AUTH_ENCRYPTION_SECRET before the gateway will even boot, more setup friction than a typical pip-install-and-go tool.
- △arm64 containers aren't supported in production, per the README, so Apple Silicon users are pushed toward Rosetta or a PyPI install instead of the native container path.
- △The Helm repository isn't published yet — the README's own Kubernetes instructions say to clone the repo and use the local chart under charts/mcp-stack rather than a normal helm repo add.
- △Local docker compose build isn't the default path either; the README warns a from-scratch local build needs a hermetic wheel closure that's only produced by the CI pipeline, so you're expected to pull the pre-built GHCR image instead.
- △SQLite is only positioned as the dev-mode database choice, per the README's Helm section — production deployments are expected to run PostgreSQL.
Alternatives to ContextForge
Who ContextForge is For
ContextForge is for platform and infrastructure teams running multiple MCP servers, internal APIs, or AI agents that need one governed entry point instead of ad hoc per-client wiring — the Admin UI, OAuth-scoped tokens, and OpenTelemetry tracing are built for that operational reality. Skip it if you're a single developer running one local MCP server for personal use: the mandatory secret generation, Postgres-backed production stack, and Kubernetes/Helm tooling are overhead you don't need at that scale, and a bare MCP server or a lighter tool like toolhive gets you running faster.
ContextForge FAQs
MCP is the protocol ContextForge federates rather than defines — the README describes ContextForge as a registry and proxy sitting in front of MCP servers, letting you pick which MCP protocol version, such as 2025-11-25, a given connection uses, and ContextForge itself also runs as a fully MCP-compliant server.
ContextForge federates MCP servers, A2A (Agent-to-Agent) agents including OpenAI-compatible and Anthropic agent routing, and REST or gRPC APIs — gRPC services get translated into MCP-compliant tools automatically via reflection-based service discovery.
ContextForge deploys as a PyPI package (mcp-contextforge-gateway) run with pip or uvx, as a Docker or Podman container pulled from GHCR, via Docker Compose for a full Postgres/Redis stack, or through a Helm chart for Kubernetes with autoscaling and multi-replica Redis clustering.
ContextForge ships an Admin UI, built with HTMX 2.0.3 and Alpine.js, giving real-time management, configuration, and a log viewer with filtering, search, and export — the README notes it also supports airgapped deployments.
ContextForge includes OpenTelemetry tracing with support for Phoenix, Jaeger, Zipkin, Tempo, DataDog, and New Relic as backends, plus structured logs, health endpoints, metrics, and LLM-specific metrics like token usage, cost, and model performance, with zero overhead when tracing is disabled, per the README.
ContextForge is built with production deployment in mind, per the README: PostgreSQL is the production database choice (SQLite is for dev), Helm-based Kubernetes deployment includes autoscaling and RBAC, and Redis-backed multi-cluster federation ships with strict SSRF protection enabled by default.
The problem it solves
Once you're running more than one or two MCP servers, each one tends to want its own auth scheme, its own transport (stdio vs SSE vs streamable-HTTP), and its own place to plug in observability — so an AI client ends up juggling a different connection method per tool instead of one endpoint. ContextForge's README frames the project's reason for existing around collapsing that sprawl: federating MCP, A2A, and REST/gRPC APIs behind one gateway with centralized governance, discovery, and observability instead of one-off integration per server.
Related repositories
Curious whether mcp-context-forge is right for you?
Let ChatGPT, Claude, or Perplexity look into it — click below and see what AI actually says about mcp-context-forge.