LiteLLM vs ContextForge MCP Gateway
Two of the top gateways, side by side: score, setup, license, activity and what each review found.
LiteLLM
OpenAI-format gateway and Python SDK for calling 100+ LLM providers
ContextForge MCP Gateway
Registry and proxy federating MCP, A2A, REST and gRPC behind one endpoint
| What we compare | LiteLLM | ContextForge MCP Gateway |
|---|---|---|
| Score parts, out of 100 | ||
| Adoption | 89, widely used | 24, niche |
| Freshness | 100, active | 100, active |
| Maintenance | 83, healthy | 90, healthy |
| Easy to run | 83, very easy | 67, easy |
| Agent-ready | 30, minimal | 70, partly |
| Facts from GitHub and the README | ||
| Stars | 60.9k | 4.6k |
| License | custom license (read the license) | Apache-2.0 (permissive) |
| Last commit | Oct 2026 | Oct 2026 |
| Last release | Oct 2026 | Sep 2026 |
| Language | Python | Not stated |
| Docker | Yes | Yes |
| GPU | Not needed | Not needed |
| arm64 or Apple Silicon | Not stated | Mentioned |
LiteLLM
LiteLLM translates calls to 100+ providers (OpenAI, Anthropic, Gemini, Bedrock, Azure and others) into the OpenAI format, either as a Python SDK or as a proxy server. The proxy adds virtual keys, spend tracking, guardrails, load balancing and an admin dashboard, and it also exposes A2A agent and MCP server gateways. The README reports 8ms P95 latency at 1k RPS.
Who it is for: Teams routing many LLM providers through one self-hosted API
Strengths
- One OpenAI-style API across 100+ providers and many endpoint types
- Proxy includes virtual keys, spend tracking, load balancing and admin dashboard
- Also gateways A2A agents and MCP servers
- Use as a Python library or as a standalone proxy
Weaknesses
- License reported as NOASSERTION; an enterprise tier exists, feature split unclear from README
- Proxy listens on port 4000 and its database requirements are not stated in the README excerpt
- Provider coverage varies by endpoint; many providers support only chat-style endpoints
- Python-based, so latency figures depend on the benchmark setup
- no GPU
- Docker + Compose
- Compose runs PostgreSQL
- Models: OpenAI, Anthropic, Gemini, AWS Bedrock, Azure
- port 4000
ContextForge MCP Gateway
ContextForge is IBM's Python registry and proxy that federates MCP servers, A2A agents and REST or gRPC APIs into one MCP-compliant endpoint with auth, rate limiting, retries, an Admin UI and OpenTelemetry tracing. It installs from PyPI (mcpgateway on port 4444), as a GHCR container, via Docker Compose with PostgreSQL, Redis and nginx, or with a Helm chart, and virtualizes legacy REST services as MCP tools.
Who it is for: enterprises centralizing MCP tools and agents behind one gateway
Strengths
- Federates MCP, A2A, REST and gRPC (via reflection) behind one MCP endpoint
- Transports: HTTP, JSON-RPC, WebSocket, SSE, Streamable HTTP, stdio
- Admin UI with live log viewer; OpenTelemetry to Phoenix, Jaeger, Zipkin
- Helm chart with HPA, Redis clustering and Grafana dashboards
Weaknesses
- arm64 containers unsupported in production; Apple Silicon needs Rosetta or PyPI
- Local Docker builds fail without the CI-only wheel closure; pull the GHCR image
- Will not start without generated JWT_SECRET_KEY and AUTH_ENCRYPTION_SECRET
- Large surface: 55+ tables, 40+ plugins, nginx and pgAdmin in the Compose stack
- no GPU
- Docker + Compose
- Needs PostgreSQL (production; SQLite for dev), Redis (caching and federation)
- Models: A2A agents: OpenAI, Anthropic, custom
- port 4444