Kong AI Gateway MCP Proxy: Translating Enterprise REST APIs into MCP Tools

By Deepak Bagada — AI Architect & Developer

By Deepak Bagada, CEO at SaaSNext & Principal AI Architect.

Every enterprise has a graveyard of REST APIs: billing systems, CRM endpoints, inventory services, internal tools — hundreds of OpenAPI documents built over a decade. Connecting AI agents to all of them by hand-writing MCP servers is a maintenance nightmare. In 2026, the pragmatic answer is a gateway-level translation layer: Kong AI Gateway's MCP proxy ingests your existing OpenAPI definitions and exposes them as first-class MCP tools, adding rate limiting, observability, semantic caching, and fine-grained access control in one place.

This guide builds an enterprise MCP proxy on Kong that turns a legacy order-management API into agent-callable tools — with zero changes to the backend service.

The Architecture: Gateway-Native MCP Translation

+---------------------------+
| MCP Clients               |
| Claude Desktop / Cursor / |
| custom agents             |
+-------------+-------------+
              |
              v
+-------------+-------------+
| Kong AI Gateway           |
| +------------------------+|
| | MCP Proxy Plugin       ||
| | - REST -> MCP mapping  ||
| | - Rate limiting        ||
| | - OTel tracing         ||
| | - Semantic cache       ||
| | - Per-tool ACLs        ||
| +------------------------+|
+-------------+-------------+
              |
              v
+-------------+-------------+
| Legacy REST Backend       |
| OpenAPI-defined services  |
| (unchanged)               |
+---------------------------+

Prerequisites and Setup

Docker + docker-compose
Kong Gateway 3.9+ (with AI plugins) or Kong Konnect
PostgreSQL (Kong's backing datastore)

For the MCP ecosystem overview, check the Daily AI World MCP Directory.

1. Docker Compose (docker-compose.yml)

version: "3.9"
services:
  kong-db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: kong
      POSTGRES_USER: kong
      POSTGRES_PASSWORD: kongpass
  kong:
    image: kong/kong-gateway:3.9
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-db
      KONG_PROXY_ACCESS_LOG: /dev/stdout
    ports:
      - "8000:8000"
      - "8443:8443"
      - "8001:8001"
    depends_on:
      - kong-db

2. Enable the MCP Proxy Plugin

Register the plugin on a Service that points at your legacy REST API:

curl -s -X POST http://localhost:8001/services \
  -H "Content-Type: application/json" \
  -d '{
    "name": "order-api",
    "url": "http://legacy-orders.internal:8080"
  }'

curl -s -X POST http://localhost:8001/services/order-api/plugins \
  -H "Content-Type: application/json" \
  -d '{
    "name": "ai-mcp-proxy",
    "config": {
      "openapi_path": "/swagger.json",
      "tools_prefix": "orders_",
      "enable_tracing": true,
      "enable_semantic_cache": true
    }
  }'

The gateway parses /swagger.json, generates an orders_* tool for each operation, and serves the MCP endpoint at /mcp.

3. Client Configuration (claude_desktop_config.json)

{
  "mcpServers": {
    "kong-order-api": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://kong.example.com/mcp"],
      "env": {
        "KONG_CONSUMER_KEY": "agent-readonly"
      }
    }
  }
}

4. Enforce Per-Tool Access Control

Create a read-only consumer and an admin consumer, then bind ACLs to specific tools:

curl -s -X POST http://localhost:8001/consumers \
  -H "Content-Type: application/json" \
  -d '{"username": "agent-readonly"}'

curl -s -X POST http://localhost:8001/consumers/agent-readonly/acls \
  -H "Content-Type: application/json" \
  -d '{"group": "orders:read"}'

# Plugin config restricts tools_acl to: orders_list, orders_get

5. Rate Limit Agent Traffic

curl -s -X POST http://localhost:8001/services/order-api/plugins \
  -H "Content-Type: application/json" \
  -d '{
    "name": "rate-limiting-advanced",
    "config": {
      "limit": [60],
      "window_size": [60],
      "consumer_groups": ["orders:read"]
    }
  }'

Security Guide: OAuth 2.0 & Zero-Trust

Expose the MCP endpoint only through Kong's OAuth 2.0 plugin with client-credentials flow. Bind issued tokens to consumer identities, then let per-tool ACLs decide what each identity may invoke. Rotate client secrets quarterly and revoke any consumer whose scope broadens unexpectedly. Every tool invocation is traced with OpenTelemetry spans carrying the consumer key, tool name, and latency, feeding your SIEM for anomalous agent behavior.

Deep-Dive Production Architecture & Unit Economics

One gateway replaces dozens of hand-written MCP servers. A mid-size enterprise with 60 internal APIs would otherwise spend $40K–$120K on bespoke MCP server development and, worse, ongoing drift as APIs change. Kong's translation layer cuts that to a configuration exercise — typically $2K–$5K in engineering time plus platform costs. Semantic caching typically removes 25–40% of repeated tool calls on stable GET endpoints, directly shrinking LLM context and backend load. P95 added latency at the gateway is under 5ms, negligible next to any model call.

Step-by-Step Production Security Checklist

1. mTLS between gateway and backend so the gateway is the only caller.
2. Per-tool ACLs with least privilege for every consumer group.
3. OAuth 2.0 client-credentials with quarterly rotation.
4. Semantic cache scoped per consumer to avoid cross-tenant data leakage.
5. OpenTelemetry spans on every tool call for audit and anomaly detection.

Explore more enterprise MCP tooling in the Daily AI World MCP Directory and keep up with platform trends on the AI news feed.

Frequently Asked Operational Questions

Does this work with non-OpenAPI backends? Kong also supports gRPC-to-MCP and manual tool schemas; OpenAPI is simply the fastest path since schemas map directly to tool inputs.

Will agents see all tools or only allowed ones? Only allowed ones — the ACL filters the tools/list response itself, so unauthorized tools are invisible to the client.

Is the MCP endpoint stateful? No — Kong's proxy is stateless per request, so you can scale it horizontally behind a load balancer without session affinity.

Final Summary & Key Takeaways

• Gateway translation eliminates bespoke MCP server sprawl.
• Rate limits and per-tool ACLs protect legacy APIs from agent traffic.
• OTel tracing makes every tool call auditable.

Build your own with patterns from the Daily AI World MCP Directory hub.

Multi-Environment Gateway Topology

Enterprise MCP proxies rarely live in one environment. The recommended topology is three stages: a development gateway against sandboxed backends with generous rate limits, a staging gateway mirroring production tool catalogs for integration testing, and a production gateway with strict per-consumer limits and read-only defaults. Promote OpenAPI changes through the same pipeline as your code: diff the generated tool list in CI, run contract tests against the MCP endpoint, and gate on any tool that disappears unexpectedly — a silent tool removal breaks agents far more subtly than an explicit failure.

Disaster Recovery & Gateway Upgrades

Because Kong's MCP proxy is stateless, disaster recovery is trivial: run two instances behind a load balancer with shared PostgreSQL, and keep a warm standby region. For upgrades, use Kong's canary plugin routing to shift a percentage of MCP traffic to the new version while monitoring error rates and p95 latency. The OpenAPI-to-MCP mapping is deterministic, so a canary diff of the tools/list response between versions catches behavioral drift before it reaches users.

Frequently Asked Operational Questions

How do I expose MCP endpoints to external partners securely? Use OAuth 2.0 client credentials with per-partner consumers, and scope each partner's ACL to exactly the tools their integration needs.

Does the proxy support MCP resources and prompts? Yes — beyond tools, it can expose OpenAPI-defined resources and prompts; most teams start with tools and adopt the others as their agents mature.

What happens if a backend endpoint is slow? Kong's timeout and circuit-breaking policies apply to MCP calls like any API call, and the semantic cache absorbs repeated identical requests from chatty agents.

Additional Implementation Notes

For teams adopting this pattern, start with a small pilot: pick one workflow, instrument it with the observability described above, and run it for two weeks before expanding. Document every failure mode you observe and feed those notes back into the retry and checkpointing configuration. Production agent systems are never finished — they are continuously hardened against the specific failure modes of the environments where they run. Pair this dispatch with the other blueprints in the Daily AI World Workflows hub and the tooling catalog in the MCP Directory to complete your production stack.