Apigee, Azure APIM and Kong each turn their APIs into MCP tools. Oxvara reads the policies on all of them, gives you one inventory of what agents can reach, and fails CI when someone weakens auth, loosens a limit or changes a tool description.
# real output from the examples in the repo $ oxvara inventory apigee@https://apigee.example.com apim kong.yaml@https://kong.example.com Agent-facing inventory: 10 tools across 3 source(s) apigee:petstore apigee_petstore_create_pet POST apiKey 10/second apim:petstore apim_petstore_create_pet POST apiKey 5000/hour kong:kong payments_refund_payment_post POST oauth2 2000/hour ... $ oxvara validate --pack strict --pack owasp-mcp ... strict+owasp-mcp: 10 operations, no violations # someone removes key-auth from a Kong service $ oxvara drift --lock oxvara.lock.json ... error auth-weakened [orders_list_orders_get]: auth went from apiKey to none error rate-limit-loosened [orders_list_orders_get]: 120/minute -> 100000/minute
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.
Oxvara normalizes every gateway into one policy model, then works from that model.
Apigee proxy bundles, APIM policy XML and Kong decK files, read with each gateway's own precedence rules. One inventory across all of them.
validate runs the strict pack and rules mapped to the OWASP MCP Top 10, with SARIF output for GitHub code scanning.
lock pins every tool's policy and description hash. drift fails when auth weakens, a limit loosens or a description changes.
One server across gateways that always calls the gateway, exchanges the user's token (RFC 8693) and audits every call.
If you run one gateway, use its native MCP feature. Oxvara is for the cross-gateway layer those features do not cover.
| Vendor-native (Apigee, APIM, Kong, MuleSoft) | Oxvara | |
|---|---|---|
| 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 |
| Inventory across gateways | Per vendor console | One table, JSON or CSV |
| Drift and tool-description pinning | No | lock + drift |
| Maturity | Shipping, supported products | Early prototype |
Why this matters: vendor features are the competition and the reason this exists. Oxvara 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.
oxvara inventory 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.