Apigee, Azure APIM and Kong each turn their APIs into MCP tools. Forgegate reads the policies on all of them, shows what agents can actually reach, and fails CI when an estate ships without auth or rate limits.
# real output from examples/apigee in the repo $ forgegate diff examples/apigee Plan for petstore 3 (3 operations). Nothing will be written. GET /pets -> petstore_list_pets auth: apiKey (x-api-key in header) rate: 200/minute POST /pets -> petstore_create_pet auth: apiKey (x-api-key in header) rate: 10/second $ forgegate validate examples/apigee strict: 3 operations, no violations
Each gateway vendor now ships a way to expose its APIs as MCP tools. That is good for one gateway. Large enterprises run several.
Apigee, APIM and Kong each have their own MCP feature, console and policy model. There is no single view of what is agent-exposed.
APIM's documentation says its policies apply to all operations exposed as tools in an MCP server, not to individual tools.
Agent tool calls and delegated identity are logged in different shapes, if at all. Auditors ask one question; you answer it three ways.
Forgegate normalizes every source into one policy model, then works from that model.
OpenAPI with annotations, Apigee proxy bundles (VerifyAPIKey, OAuthV2, Quota, SpikeArrest) and APIM policy XML.
diff shows which tools exist and which policy each inherits. validate applies the strict pack and exits non-zero in CI.
Optional compile step produces a runnable server with inherited auth, client-side rate limits, OAuth2, an audit log and encoded path parameters.
If you run one gateway, use its native MCP feature. Forgegate is for the cross-gateway layer those features do not cover.
| Vendor-native (Apigee, APIM, Kong, MuleSoft) | Forgegate | |
|---|---|---|
| Expose APIs as MCP | Yes, inside that vendor's platform | Optional, via a generated standalone server |
| Scope | That vendor's estate only | One policy model across sources |
| Per-tool policy view | Varies; APIM applies policy at server level | Per operation, shown in diff |
| CI gate on policy gaps | Not a built-in concept | validate with policy packs |
| Cross-gateway drift detection | No | Planned |
| Maturity | Shipping, supported products | Early prototype |
Why this matters: vendor features are the competition and the reason this exists. Forgegate is only worth using where more than one gateway is in play.
Early prototype. Not production-ready. Prompt-injection controls reduce risk but do not eliminate it. The repo's README states exactly what is and is not built.
Cloud and API architect with Apigee X migration and multi-cloud API design experience. Building this in the open.
forgegate diff on your estate.Running more than one API gateway? I am looking for a handful of design partners for a 20-minute conversation. Read-only, no data leaves your machine.