Zerker vs ContextForge
Context Forge governs. Gateway also charges.
IBM's MCP Context Forge is broader than Gateway: more protocols, more plugins, more stars, and a vendor name procurement already knows. It cannot charge for a call. If monetization is a requirement, that is most of the comparison.
Self-host it. Charge for it. Keep payment keys yours. Zerker combines self-hosting, payment gating, and no custody in one open-source Gateway.
Start here
Breadth, or one binary that meters.
ContextForge governs a fleet of agent tools. Gateway stands in front of them and can put a price on each call.
Pick ContextForge if
- You need A2A in the gateway today
- You're standardised on OpenTelemetry and need export now, not later
- You want the widest plugin surface: PII filtering, guardrails, caching, OPA and Cedar policy, and more
- Python, Redis and Kubernetes are already what you run, so that stack costs you nothing
- IBM's name on the project matters to whoever signs off
Pick Zerker if
- You need to sell agent-tool access, not only govern it
- You want one static Go binary instead of Python plus Redis plus Kubernetes
- You want payment verification that holds no key and makes no outbound call
- Your deployment target is small, sovereign, or air-gapped and a platform stack is a burden
Where they're ahead
What Context Forge does better.
ContextForge covers MCP, A2A, and REST/gRPC, ships full OpenTelemetry, carries a large plugin catalogue across security, reliability, compliance, and policy, and has roughly forty times our GitHub following, with IBM behind it.
On protocol coverage, observability export, ecosystem, and backing, they win. We are newer, narrower, and smaller.
Side by side
Where they differ.
| ContextForge | Zerker | |
|---|---|---|
| Payments | None. No plugin, in any category, as of v1.0.6 | x402 gate in the OSS core; facilitator settlement in progress |
| Stack | Python, Redis, Kubernetes | One static Go binary and a Postgres |
| Protocols | MCP, A2A, REST/gRPC, LLM APIs | MCP over Streamable HTTP, plus generic HTTP |
| Observability | Full OpenTelemetry export | In-product records and analytics. No OTLP export yet |
| Plugins | A broad catalogue — guardrails, PII, caching, OPA and Cedar policy | Policy evaluation on the proxy path. No plugin ecosystem |
| Auth | OIDC / JWT / RBAC | Mandatory OIDC; per-tenant envelope-encrypted credentials |
| Backing | IBM, ~4k GitHub stars | A small team, and far fewer |
| License | Open source | Apache-2.0, open core. Money movement is the paid half |
The actual difference
A gateway that says no, and one that says not until you pay.
ContextForge decides whether a call is allowed. Nothing in it decides whether a call has been paid for. Gateway does both, and the payment gate is in the open-source binary.
This is a difference today, not a moat. ContextForge has a plugin architecture and a large contributor base, and a payments plugin could exist. That is why this page is dated.
Sources
Compared against publicly available information on 3 August 2026, against ContextForge v1.0.6 (released 22 July 2026). The payments claim was checked directly against their published plugin catalogue — available plugins — which lists eight categories, none transactional. Project: github.com/IBM/mcp-context-forge. If they ship payments, this page is wrong the day they do; please open an issue and we'll update it.