The most-starred open-source MCP gateway, against a managed credential-custody gateway. ContextForge federates and governs servers, with the best token-narrowing model in the category. KnoxCall holds the credentials and covers your model traffic with the same controls. If self-hosting is a hard requirement, this comparison has a short answer and it is not us.
Give them their due
Read from the project's own repo and docs on 2026-08-25 — github.com/IBM/mcp-context-forge (Apache-2.0) and its documentation site. We picked it as the open-source comparator on displayed stars: 4.4k against 959 for the next candidate, and it is the only one with a documented multitenancy model at v1.x.
tool_pre_invoke / tool_post_invokeWhere they differ
Each row cites both halves. ContextForge's column is read from the repo and docs linked above; ours comes from the same code citations behind our control table. Where we could not evidence something, the row says so.
| IBM ContextForge | KnoxCall | |
|---|---|---|
| Licence and hosting | Apache-2.0, self-hosted, multi-cluster federation. v1.0.0 on 2026-08-13, v1.0.8 on 2026-08-18 | Proprietary managed SaaS. No self-hostable core — if that is a hard requirement, stop reading here |
| Vendor support | An IBM-owned Apache-2.0 GitHub project. No production-readiness or support statement anywhere we could find — do not read "IBM" as a warranty | A managed service from a small company. Different risk, not obviously a smaller one; weigh both |
| Access model | Team-scoped RBAC with four roles; personal team per user; Private/Team/Public visibility, default private | Tenant-scoped, with agents and MCP servers as the unit; team roles are the platform's, not per-tool |
| Token narrowing | The sharpest in the category: a missing teams claim yields public-only access even for an admin, and the claim "only narrows, never broadens" the DB result |
A different axis, same fail-closed instinct: RFC 8707 binds a token to one server — wrong resource 401, unbound 401, non-tool-bound 403 |
| Empty tool allowlist | Visibility-driven rather than allowlist-driven; we could not evidence an empty-set-denies rule | Empty advertises nothing; the caller's token intersects, never unions |
| PII on tool arguments | Bundled PIIFilterPlugin on both invoke hooks: SSN, email, credit card, configurable | Built-in detectors on arguments and results. Your own custom recognizers do not reach the MCP path yet — model calls get both |
| Provider credential custody | Auth is Basic/JWT/custom, OAuth 2.0 with user-scoped tokens, DCR. Upstream credentials live in configuration you host, patch and back up | Envelope-decrypted and injected at the egress hop; the workload only ever holds a KnoxCall token. Or forward the caller's own credential in passthrough mode |
| Model traffic | Out of scope — it is an MCP and tool-federation gateway | Same gateway: USD budgets, model allow/deny, prompt-injection screening, mid-stream PII redaction |
| Documented gaps | Server-registration and federation-sync plugin hooks marked planned; public-team join flows "to be implemented"; default visibility not settable by env; no bundled policy-engine plugin | Ours are on the MCP Gateway page in a table with three states, not in a footnote |
One caveat on their gap list, in their favour. The planned-hook labels in the documentation cite v0.9.0 and v0.10.0 while the shipped release is v1.0.8, so some of those may be stale doc text rather than live gaps. We are recording that rather than banking the point, because a comparison built on a competitor's stale docs is a comparison with a shelf life.
And the honest summary. On token narrowing, ContextForge is at least our equal and arguably ahead. On PII inspection of tool arguments, both ship it. Where we differ is custody — who holds the upstream credential, and whether the same controls cover your model calls — and whether you want to operate the gateway yourself. Those are the questions worth deciding on, and neither answer is universally right.
Choosing
self-hosting is a hard requirement, you are federating many heterogeneous servers (MCP, A2A, REST, gRPC) into composed virtual servers, or you want team-scoped RBAC administered in your own cluster with your own IdP. It is the most capable open-source option in the category and we would say so to your face.
the thing keeping you up is where the upstream credential lives — and you would rather it was never in your workload or your config repo at all — or you want one gateway and one audit trail across tool calls and model calls, without operating it.
ContextForge in front, federating and team-scoping your servers; a KnoxCall route behind it so the upstream credential is injected at our egress hop rather than sitting in the config you deploy. Neither design forbids the other.
No, and this is the single thing most worth getting right before you plan around it. It is an IBM-owned Apache-2.0 project on GitHub. We looked for a production-readiness statement or a support commitment anywhere in its documentation and releases and found none, so describing it as IBM-supported would be inventing a warranty its own authors have not offered. That is not a knock on the software, which is the most capable open-source gateway in the category by some distance. It is a procurement fact. Verified on 25 August 2026 against github.com/IBM/mcp-context-forge and ibm.github.io/mcp-context-forge.
Yes, and it is one of the few in the category that does. It bundles a PIIFilterPlugin on the tool_pre_invoke and tool_post_invoke hooks with configurable social security number, email and credit-card detection, and it can call external plugins over MCP or gRPC, including LlamaGuard and OpenAI Moderation. If a comparison page told you open-source MCP gateways cannot see tool arguments, it had not read this one.
Its token scoping, and we think it is the best in the category. Access is driven by the JWT teams claim, a missing teams key yields public-only access even for a platform administrator rather than everything, and for session tokens the documentation states that the database is the authority and the JWT teams claim only narrows, never broadens, the result. That is a fail-closed default and a narrow-only rule, which is exactly the shape a token claim should have. Our RFC 8707 resource binding does the same job on a different axis: it binds a token to one server rather than narrowing a team set.
Credential custody, and the model plane. ContextForge federates servers and governs who may reach them; the upstream credentials still live in configuration you host and back up. KnoxCall envelope-decrypts the provider credential and injects it at the egress hop, so the workload only ever holds a KnoxCall token, and the same gateway governs your model traffic with budgets, model policy and mid-stream PII redaction on one bill. It is also managed, which is a disadvantage if self-hosting is a requirement and an advantage if operating a gateway is not what you want to be doing.
If self-hosting is a hard requirement, yes, and ContextForge is the one we would look at first: Apache-2.0, multi-cluster federation, OpenTelemetry, Prometheus, an admin UI, and SSO against GitHub, Google, Entra ID, Keycloak, Okta or generic OIDC. KnoxCall is proprietary managed SaaS with no self-hostable core, and no comparison page of ours will pretend otherwise. What you take on in exchange is the operations: you hold the upstream credentials, you patch the gateway, and you own the availability of the thing every agent call goes through.
Audience-confined tool tokens, provider keys injected at the egress hop, the same controls on model calls — free to start.