ContextForge review
Python gateway and registry that puts MCP servers, A2A agents and REST or gRPC APIs behind one endpoint, with teams, SSO and plugins
Data refreshedMethodologyHow we testedChandan Kumar is a founder of Geekflare. He is a technology enthusiast and entrepreneur who loves to help businesses and people around the world. Chandan has worked at BNP Paribas, Citibank, Deutsche Bank, Motorola, and HP. He’s got an in-depth understanding of business software and IT infrastructure.
Verdict
ContextForge puts a lot of the gateway job in the free version: virtual servers built from MCP tools, REST and gRPC APIs, SSO with team roles, an audit trail and a plugin layer for PII and policy checks. The catch is its size and security record, with about 300 settings and 19 published advisories in 2026, several of them critical, fixed by version 1.0.7.
Best for
Platform teams that want SSO, team roles and REST-to-MCP in a free gateway
Not for
Teams that want a small proxy with little to configure
Pros
- SSO, team roles and an audit trail are in the free version
- Turns REST and gRPC services into MCP tools without writing a server
- Plugin hooks before and after tool calls, with PII, deny-list, OPA and Cedar plugins
- Also routes A2A agents and proxies LLM calls
Cons
- 19 security advisories in 2026, several critical, all fixed by version 1.0.7
- More than 300 settings, and secrets must be generated before the first start
- No arm64 container support in production and no published Helm repository
Ask SparkianIs ContextForge right for your project?
Describe what you need and AI will check the fit against this review.
ContextForge features and capabilities
Virtual servers
Tools from several MCP servers and APIs can be picked into one virtual server with its own URL, so each agent sees only the tools it needs.
REST and gRPC as MCP tools
An internal REST endpoint or gRPC service can be registered as a tool, with input schemas taken from its OpenAPI spec or gRPC reflection.
Teams, SSO and scoped tokens
Users sign in through Entra ID, Okta, Keycloak or another OIDC provider, land in teams by group, and get API tokens limited to their teams.
Plugin hooks on every call
Plugins can inspect or block tool calls, prompts and results, for example to mask PII, apply OPA or Cedar policy or send content to LLM Guard.
Federation between gateways
Several ContextForge instances can share tools with each other, so regional or team gateways can be joined behind one entry point.
- One endpointCombines tools from several MCP servers behind one URL
- YesVirtual servers combine tools from many sources
- Client authOAuth, OIDC or keys for the agents and users calling the gateway
- YesJWT API tokens, OIDC SSO and OAuth
- Per-tool accessAllows or denies individual tools per user, team or key
- YesPer-team visibility and virtual servers; OPA or Cedar for finer rules
- Server catalogA registry of approved MCP servers that teams can pick from
- YesYAML catalog shown in the Admin UI
- API to MCPTurns existing REST or OpenAPI APIs into MCP tools
- YesREST with OpenAPI schemas, and gRPC via reflection
- Sandboxed serversRuns local MCP servers in containers or another sandbox
- NoDoes not run servers itself; docs say to sandbox them
- GuardrailsChecks tool calls for prompt injection, secrets or PII
- YesPII, deny-list and moderation plugins, off until enabled
At a glance
- Type
- MCP gateway and registry
- Stack
- Python
- Databases
- SQLite, PostgreSQL, Redis
- SSO
- Free edition
- Roles and permissions
- Free edition
- Audit logs
- Free edition
Free vs paid editions
What you get when you self-host, and what needs a paid plan.
Everything in the repo is Apache 2.0, including SSO, teams, roles, the audit trail, the plugin framework and the Admin UI, and IBM says it does not hold features back for a paid edition. IBM sells IBM Elite Support with SLAs for version 1.0.0 and later, plus consulting, but publishes no price. There is no hosted version, only deployment guides for AWS, Azure, Google Cloud, IBM Code Engine and OpenShift.
Self-hosting ContextForge
ContextForge gives no minimum requirements, but its Helm chart runs two gateway pods that each request half a CPU and 768 MB of RAM, plus PostgreSQL and Redis.
New cloud server to ready
29 s
Memory in use at idle
847 MB of 4 GB
Median tool call
47.5 ms
Calls/s, 8 sessions
25
Peak memory
1,345 MB
Version tested
1.1.0 · Oct 30, 2026
- It refused to start until I generated strong secrets with its own script: the default user password must be 12 characters or more. It was then ready in 29 seconds and used 847 MB at idle, because it starts five gunicorn workers.
- Every request needed a JWT, and it blocked my reference server on the Docker network as a private address until I allowed that subnet with SSRF_ALLOWED_NETWORKS. Geekflare's remote server registered straight away, and the two gave 40 tools.
- A virtual server with two chosen tools exposed exactly those two. Through the full one, tool calls took a median of 47 ms, against 5.7 ms direct, and 8 sessions managed 25 calls a second.
- Its default rate limit of 100 MCP requests a minute stopped my first benchmark with 429 errors, so plan to raise RATE_LIMIT_MEDIUM_RPM for agents that make many calls.
# Secrets from its own generator; the gateway refuses to start with weak ones
docker run --rm --entrypoint python ghcr.io/ibm/mcp-context-forge:v1.1.0 \
-m mcpgateway.scripts.init_secrets --stdout > secrets.env
docker run -d --name contextforge -p 127.0.0.1:4444:4444 \
--env-file base.env --env-file secrets.env \
-e SSRF_ALLOWED_NETWORKS='["172.18.0.0/16"]' \
ghcr.io/ibm/mcp-context-forge:v1.1.0
# Admin token, then register both servers and build a virtual server from their tools
T=$(docker exec contextforge python -m mcpgateway.utils.create_jwt_token \
--username admin@example.com --exp 240 --secret "$JWT_SECRET_KEY")
curl -X POST localhost:4444/gateways -H "Authorization: Bearer $T" -H 'Content-Type: application/json' \
-d '{"name": "everything", "url": "http://everything:3001/mcp", "transport": "STREAMABLEHTTP"}'
curl -X POST localhost:4444/servers -H "Authorization: Bearer $T" -H 'Content-Type: application/json' \
-d '{"server": {"name": "two-tools", "associated_tools": ["<echo id>", "<dnsRecord id>"]}}'
# Clients connect to http://localhost:4444/servers/<server id>/mcp with the token{
"timestamp": 1793384207909,
"apiStatus": "success",
"apiCode": 200,
"meta": {
"url": "geekflare.com",
"test": {
"id": "066e2cc5-5ed0-4143-96bc-b057d0923bae"
}
},
"data": {
"A": [
"104.26.0.30",
"172.67.72.144",
"104.26.1.30"
],
"AAAA": [
"2606:4700:20::ac43:4890",
"2606:4700:20::681a:11e",
"2606:4700:20::681a:1e"
],
"MX": [ … ],
…What you can do with ContextForge
Company-wide MCP endpoint
Register internal and third-party MCP servers once and give each team a virtual server with only the tools it is allowed to use.
Expose internal APIs to agents
Wrap existing REST or gRPC services as MCP tools so agents can call them without anyone writing a new MCP server.
Governed agent access with SSO
Let staff sign in with Entra ID or Okta, map their groups to teams and keep an audit trail of changes and token use.
ContextForge alternatives
agentgatewayRust proxy for LLM, MCP and agent-to-agent traffic, with per-key budgets, guardrails and a built-in UI
Docker MCP GatewayDocker CLI plugin that runs MCP servers from a catalog in isolated containers and serves their tools to clients through one gateway
ToolHiveRuns each MCP server in its own container, locally or on Kubernetes, with a virtual MCP gateway, a registry server and Cedar policies per tool
ObotSelf-hosted control plane with an MCP gateway, a Git-backed server catalog, hosted MCP servers, an LLM gateway and audit logs
MCPHubSelf-hosted MCP gateway that puts many MCP servers behind one endpoint, with groups, scoped keys, per-user credentials and a web dashboard
UnlaGo gateway that turns REST APIs into MCP servers through YAML config and proxies existing MCP servers, with a web UI for managing them