MCP when the model can call your APIs

MCP, Kong, API security, agents

A short tutorial, with Kong as the secure path: MCP is how a model proposes tool calls — the gateway decides what runs.

A model that can call tools is useful. A protocol that lets it do so is not the same as a policy that says it may.

MCP is how a client discovers and invokes tools a model can call. Over HTTP, the authorization spec (2025-06-18) also defines OAuth: the MCP server is the resource server, the MCP client is the OAuth client, and the authorization server issues an access token meant for that server. Authorization is optional. stdio is outside that flow.

That is still not your enterprise policy. Protocol auth does not decide which identity may invoke which tool, against which resource, at what rate, or with what audit trail. Those decisions sit at enforceable boundaries: the gateway and the upstream service.

What MCP is

MCP is a protocol between a client and a server that exposes tools. The model proposes a tool call. Something has to decide whether it runs.

Two shapes matter:

  • Local. The server runs on the same machine as the client, often over stdio. Fine for a demo. That path is not the HTTP OAuth flow above.
  • Remote. The server is on the network. Now you have the same problems as any API: who is calling, what they may do, and what gets logged.

A raw MCP server is the model talking straight to whatever sits behind the tools. Optional OAuth on HTTP does not replace a gateway or the upstream’s own checks.

Three ways agents talk to systems

Don’t treat every “agent protocol” as the same thing.

  • OpenAPI describes HTTP APIs a client already knows how to call.
  • MCP describes tools a model can discover and invoke, and, over HTTP, how a protected server can take part in OAuth.
  • Agent-to-agent is models (or agents) talking to each other, not to your API.

A token issued for a person in a browser, or for a different resource, is the wrong credential here. The token has to be for this server. Audience is how you stop a bearer token for one resource from being accepted by another.

Kong in front, not beside

Kong’s path is to put the AI Gateway in front of the tools.

The AI MCP Proxy does one of two jobs:

  • Turn existing REST into MCP tools, so you don’t stand up a new server for every API.
  • Pass an MCP server through, so the gateway still sits on the path.

Those are not the same proxy. When Kong converts REST into tools, Kong is the client of the upstream API. When it passes MCP through, Kong enforces policy and forwards, and the MCP client still starts the session.

The secure path

The AI MCP OAuth2 plugin is the resource server on that path.

  1. It checks the bearer token and the audience.
  2. If that check fails, it returns 401. The tool does not run.
  3. If it passes, it strips the caller’s token before the upstream. That is the default. The MCP spec says a server must not pass that token upstream.

Do not put AI MCP OAuth2 on the same route as AI MCP Proxy in conversion-listener mode. It belongs with listener or passthrough-listener. REST exposure is conversion-only, on a separate route. “Passthrough only” is too narrow.

Token exchange (Kong Gateway 3.14+) is the other option. The gateway keeps the caller’s credential only long enough to swap it for a token meant for the upstream. That is not the same as forwarding the original bearer token, and it is not a switch you should treat as “just pass it through.”

Checking the token is not the same as allowing this tool. The gateway still does not prove the model picked the right call, or that the arguments match what the user meant. Tool descriptions and tool results are data, not policy.

On top of the token check:

  • Rate limits, so a chatty model cannot stampede an API.
  • Read-only routes, so a tool that should only look cannot write.
  • Konnect observability, so you can see what was called, not just what the model claims it called.

OAuth at the gateway is necessary where the route is protected. It is not sufficient. Pair it with a decision about this tool, a credential meant for the upstream, and a record of what ran.

Further viewing: Kong AI Gateway 2.0: How to Create MCP Servers, MCP Servers Explained & Built, and MCP & Agent Protocols: Securing APIs in the Agentic Era.

What can fool you

  • Fool mode: expose an MCP server, paste a token into the client, and call it secured because OAuth is “on.”
  • Honest mode: the token is for this server, a bad token is 401, the upstream does not see the caller’s bearer token, and OAuth2 sits on a listener or passthrough-listener route — not on the same route as conversion-listener.

A local server with no auth is a prototype. A remote server that forwards the caller’s bearer token is how one credential becomes every hop’s credential.

Closing

MCP is how the model proposes tool calls, and over HTTP it can say who presented a token for this server. It does not decide your policy. Kong is one way to put that decision in the gateway instead of in the prompt.

The model proposes tool calls. The gateway decides.