"Too much information running through my brain." When The Police sang this opening line on their 1981 album Ghost in the Machine, they weren't thinking about artificial intelligence, but the sentiment perfectly captures the state of modern AI.
The song warns of an overload of data that parallels how modern AI agents process extensive collections of messages and data. Model Context Protocol (MCP) is designed to manage this potential mess by creating channels for models to receive only the information they need. In a world where AI systems risk becoming "information junkies," MCP acts as a framework that organizes data, allowing AI to operate in a standardized and much cleaner way.
In the latest Kong Gateway 3.12 release, announced October 2025, specific MCP capabilities have been released:
The Kong AI Gateway sits in between the AI applications we build and the MCP Servers and GenAI models we consume.
In fact, the Kong MCP Gateway sits side-by-side with the Kong LLM Gateway. Here is a diagram illustrating the components. As you can see the Kong AI Gateway implements the fundamental capabilities as the LLM Gateway and MCP Gateway are responsible for their specific flows: MCP servers and GenAI models.
This blog post explores how developers can leverage Kong MCP Gateway to implement better and smarter AI agents. We are going to focus on:
We’ve seen a lot of momentum around the Model Context Protocol (MCP), the new standard proposed by Anthropic in November 2024. For a great introduction to MCP, check the blog Michael Field, Principal Technical Product Marketing Manager here at Kong, wrote early this year.
As described in its official portal, MCP follows a client-server architecture where an AI application (tool or AI Agent) connects to MCP Servers. The MCP specification defines three participants as illustrated above in the diagram taken from the MCP portal:
Each MCP Server is responsible for exposing MCP primitives to the Clients:
Check the Architecture Overview page in the MCP documentation portal to learn more about it.
Currently most organizations still don’t have a consistent way to standardize the MCP development process or enforce best practices. As you’d expect, this often results in risky MCP server deployments and, iIn the long run, it also means longer and more expensive evolving and troubleshooting processes.
With Kong MCP Gateway we expose and secure all MCP Servers in a single place. Also, the MCP Gateway controls the consumption of the MCP Servers with OAuth 2.1, as described in the MCP documentation portal.
MCP introduces the notion of Layers:
Data layer: defines the protocol for MCP Client and MCP Server communication, based on JSON-RPC 2.0.
Transport Layer: defines the mechanisms to enable the data exchange between the MCP Client and MCP Server. Basically it supports two mechanisms:
For the purpose of this blog post, where the Kong AI Gateway mediates the communication between the MCP Client and MCP Server, we are going to focus on the Streamable HTTP mechanism.
To get started, let's exercise a little bit the JSON-RPC messages we typically have in a MCP communication. To put simply, JSON-RPC is an RPC-based mechanism where the parts communicate through JSON based messages.
For example, here's a simple JSON-RPC server, written in Python, which exposes the well-known WeatherAPI public service. To give it a try, you can call the service directly with the following request. It assumes you have an environment variable set with your WeatherAPI API Key.
The architecture is quite simple:
The code uses the "json-rpc" Python package, which implements the JSON-RPC specification. Some comments about the code:
After starting the server, you can send requests like these ones:
Let's take a look at the messages going back and forth. The latest request sends a message like
The message is fully compliant with the JSON-RPC 2.0 specification where it defines the Request Object with the following members:
The Server is expected to return a Response Object. That's done by the JSONRPCResponseManager class imported from the same “jsonrpc” package. Here's ours:
The Object has the following members:
This is a good exercise but does not really implement our goal. What we really want is to have the Kong Data Plane playing the MCP Server role. That means we need to configure the Data Plane with the new MCP Gateway capabilities. However, before doing so, we need to dive a bit deeper into the MCP Transport Layer.
As stated before, MCP defines two transport mechanisms: Stdio and Streamable HTTP. Since we are going to add Kong AI/MCP Gateway in our cases, we are going to focus on Streamable HTTP.
We can build Streamable HTTP-based MCP Servers using multiple programming languages, for example, TypeScript, Python or C#. Specifically for Python, FastMCP packages are recommended. In fact, the official MCP Python SDK has incorporated FastMCP to provide a simpler MCP Server development.
Here's the MCP Server version, using FastMCP, of our JSON-RPC 2.0 Server. As you can see the topology and the messages going back and forth are quite similar to it.
Some comments here:
With the MCP Server running, we can send similar JSON-RPC requests to it. For example, to list all tools available in the MCP Server run:
Note that the Server provides a specific “/mcp” path where we should send requests. Also, the client (in our case, Curl) must accept both “application/json” and “text/event-stream” media types.
The MCP Server provides several methods to expose its capabilities, including Prompts, Resources, and Tools. For example, our MCP Server code defines three Tools: “ping”, “add”, and “get_current_weather”. With the request above, we can send a request to the MCP Server and get the list of its Tools with all their specifications.
Here's the output of the request:
The request and the corresponding response follow the Transport specification for sending messages to a server.
And this second request calls the “get_current_weather” Tool:
And the response should follow the Tools specification and be something like:
Now, let's add the Kong API Gateway to the picture. Our goal is to have the Konnect Data Plane to keep exposing regular RESTful-based services as well as playing the role of the MCP Server. In order to do it, we need to introduce the new AI MCP Proxy plugin available in Kong AI Gateway 3.12.
The new plugin can be configured for the following main use cases:
As you can see, for any of these use cases, Kong, playing the MCP Gateway role, provides critical values to the Agent development processes, normalizing the access to any MCP Tool or MCP Server you might have in your environment.
Let's get started converting an existing Kong Gateway Service into an MCP Tool. The following diagram illustrates the architecture:
Consider the following decK (Declarations for Kong) declaration defines a fundamental Kong Gateway Service and Kong Route to expose the same WeatherAPI service, this time, through the Gateway.
Besides the Kong Service and Route, the declaration enables the Request Transformer Advanced Plugin to the Route to inject the WeatherAPI API Key. Again, we have an environment variable with the API Key. The env variable is named with the DECK_ prefix so decK can take care of it.
After submitting the declaration, you should be able to consume the Kong Route like this:
Up to this point, the Kong Gateway Service is not configured to be consumed as a MCP Tool. In order to do it, we need to extend the decK declaration:
This time, the Gateway Service has its route configured with the AI MCP Proxy plugin. The “conversion-listener” mode says the Gateway Service can be consumed as a MCP Tool. Inside the “tools” section, the “parameters” configuration has an OpenAPI snippet describing the parameters the plugin should send to the Gateway Service.
Differently to what we did before with our basic MCP Server, the AI MCP Proxy plugin implements the full MCP Connection Lifecycle as described in the MCP documentation. The lifecycle comprises the main phases:
Let's send specific requests to each one of them:
Initialization
You should get a response like this. Note that, following the specification, the plugin has generated a “mcp-session-id” which can be accessed in the output header. The next request should include the header.
The second request should be an “initialized” notification:
And here's the response:
Now, with the MCP Session defined, let's send some requests to the MCP Gateway. The first one asks the Gateway to list the Tools available:
The expected and formatted response is the following. Note that the plugin names the Tool following the format “weather-route-1”. The parameter is also defined with the format “query_q”.
And here's the actual Tool call. The request should refer the actual name defined by the plugin and parameter name.
The response should be like:
The last thing a client should do is to send a Shutdown message to the MCP Tool to gracefully terminate the connection.
The response should like:
To get a more realistic client, here's a very simple example of a MCP Client consuming the MCP Tool, exposed by the Kong AI Gateway. The MCP_DN and MCP_PORT define where the Konnect Data Plane is located.
As you might have noticed, until now, there's no security mechanism defined to protect the MCP Tool exposed by the Kong AI Gateway. As usual, you can take advantage of the historical plugins the Kong API Gateway provides to implement Authentication and Security processes to your MCP Tool, such as Key Auth, OpenID Connect, Open Policy Agent, etc.
On the other hand, the MCP community has defined Authorization specifications, based on OAuth 2 standards. To be fully compliant with the specs, the Kong AI Gateway provides a second plugin, responsible for implementing those specs: the AI MCP OAuth2 Plugin.
To exercise the new plugin, let's extend the decK declaration one more time:
The exercise relies on Keycloak, as the external Identity Provider. In this sense, Keycloak is responsible for issuing Access Tokens and validating them during the MCP Tool consuming time. The validation follows the OAuth2 Token Introspection specification.
The following diagram shows the relationship between the Kong AI Gateway and the Identity Provider (IdP) for the Introspection flow:
To get Keycloak installed you can follow the Quickstarts available.
The declaration refers to some Keycloak endpoints and secrets, besides the actual Authorization URL. Let's go through them:
MCP_AUTH_URL: that's the MCP Tool URL, exposed by the Kong Data Plane. Considering our declaration should be like this: http://<DATA_PLANE_DN>:<DATA_PLANE_PORT>/weather.
KEYCLOAK_AUTHZ_URL: that's the Keycloak Authorization endpoint. Assuming an existing Keycloak realm, called “kong”, in our case, it should be something like: http://<KEYCLOAK_DN>:<KEYCLOAK_PORT>/realms/kong/protocol/openid-connect/auth.
KEYCLOAK_INTROSPECTION_URL: that's the Keycloak Introspection endpoint. In our case, http://<KEYCLOAK_DN:KEYCLOAK_PORT/realms/kong/protocol/openid-connect/token/introspect.
CLIENT_ID and CLIENT_SECRET: these are the secrets of an existing Keycloak Client.
Keycloak provides the standard endpoint http://<KEYCLOAK_DN:KEYCLOAK_PORT/realms/kong/.well-known/openid-configuration where you can get these and several other Keycloak configuration parameters.
To exercise the Introspection Endpoint, let's send some requests to Keycloak, acting as the Consumer and the Gateway.
In the first request, we play the Consumer role, using the Client Credential Grant to get our Access Token
You can decode the Access Token with:
You should get an output like this:
Now, playing the Gateway role, we are going to consume the Introspection Endpoint asking the IdP to validate the Access Token:
Here's a typical response. The “active” at the bottom says the plugin is still good.
However, if you wait for the Access Token timeout (in Keycloak is 10min, by default), the Endpoint returns a different output saying so:
Now, let's evolve our MCP Client and protect it with the AI MCP OAuth2 Plugin. The code has a new function called “get_access_token” which is responsible for hitting the Keycloak's Authorization Endpoint to get the Access Token. The token is then used to start the Streamable HTTP Session.
The code checks if a specific environment variable is defined with an Access Token. If it is, the code uses it to start the Session. One nice way to test the code would be running the code, setting the environment variable with the token, waiting for the timeout and running the code again. You should see an error message related to it.
Now we are going to explore the other main use case implemented by the AI MCP Proxy Plugin which is to expose and protect an existing MCP Server. For the use case we are going to use two of them: Kong MCP Server and AWS Knowledge MCP Server.
The Kong MCP Server was introduced last April, 2025 and it's available in GitHub. The Kong MCP Server allows you to interact with Konnect and get current configuration about your Control Planes, Kong Objects (Service, Routes, Plugins, Consumers), etc.
For the purpose of this blog post, you can deploy the Kong MCP Server in Kubernetes using these declarations.
Create a namespace and two secrets: one for the Konnect region and another for the your Konnect Access Token (e.g. PAT)
Now submit the declaration for the Kubernetes Deployment and Service. The Services annotations are specific for Amazon EKS and AWS Load Balancer Controller. Ideally, the Service should be deployed with an internal Load Balancer; however, to make it consumable even without the Gateway, we are deploying it with an internet-facing NLB (Network Load Balancer).
Once you have the Kong MCP Server deployed, you can start consuming it just like you did with the MCP Server we crafted before. However, we want this MCP Server to sit behind the MCP Gateway and get controlled by it.
That's where the second AI MCP Proxy use case comes in: to proxy MCP requests to existing MCP Server. The architecture is illustrated below:
Here’s our new decK declaration:
The declaration creates a new Kong Gateway Service based on the Kong MCP Server URL. In this case, the Kong MCP Server was deployed in the same Kubernetes as the Kong Data Plane so we can use the Kong MCP Server's Kubernetes FQDN to connect to it. As expected the Route is reachable with the “/mcp” path.
The AI MCP Proxy plugin is one more time configured, but this time with the config mode as “passthrough-listener”, meaning the MCP Gateway will listen for incoming MCP requests and proxies them to the upstream URL of the Gateway Service (http://mcp-konnect.kong:30001/mcp). The main benefit is the MCP observability metrics generation for traffic.
After submitting the declaration, we can check the MCP Server. This time, we’ll use the MCP Inspector tool provided by the MCP project. You can run it as a container in your Docker or Podman environment. For example, for Podman, run the following command:
If you want to stop it and delete it, run:
Check the MCP Inspector logs and get the Session Token:
In MacOS, start the application with the following command. You should get redirected to the MCP Inspector home page.
For “Transport Type” choose “Streamable HTTP” and add your Kong Data Plane URL (e.g. http://k8s-kong-kongkong-fae959197b-6192eafba1fb8e62.elb.us-east-2.amazonaws.com/mcp). Make sure you have set the Connection Type as “Via Proxy” so the requests go through the MCP Inspector's MCP Proxy.
Click “Connect". MCP Inspector should open the “Tools” box. Inside the box, click “List Tools” to see all MCP Tools exposed by the Kong MCP Server. Choose “list_control_planes” and you should see a new box with all parameters available to run the Tool. Click “Run Tool” and see the results:
At the same time, Kong AI Gateway is generating observability data related to the MCP Server and Tool consumption. Here's the Kong Gateway Service “mcp-service” Analytics landing page.
AWS provides a long list of MCP Servers. A particularly interesting one is the AWS Knowledge MCP Server which provides real-time access to AWS documentation.
A similar decK declaration can be used to consume it:
This time, to consume the external MCP Server, we are going to use Insomnia, the AI-native API platform for developers to design and test any endpoint, including MCP client support. Read the documentation to learn more about it.
Inside Insomnia, start a new or use an existing Project. Click on “+” for MCP Client.
Return to Kong AI Gateway Analytics options and choose “Explorer”. Change the time period to “Last 15 minutes”, and show “Request Count” per “10 seconds” by “Gateway service”. You should see a diagram showing the consumption of both MCP Tools.
In this blog post, we explored how Kong MCP Gateway can serve as a powerful bridge between AI agents and enterprise systems by exposing internal capabilities through the Model Context Protocol. With Kong’s flexible plugin ecosystem and first-class support for MCP, it becomes straightforward to integrate tools, data sources, and downstream APIs in a secure and scalable way. Beyond simple tool invocation, Kong MCP Gateway enables advanced agentic patterns such as multi-step workflows, contextual enrichment, and safe function calling, while maintaining strong governance over every interaction.
Just like we do with traditional API workloads, the MCP Gateway can be combined with the rich set of Kong plugins to strengthen and enhance AI-based use cases. For example, you can protect MCP tool endpoints using the MCP OAuth2 Plugin.
To explore the full set of capabilities available for building MCP-enabled architectures, visit the Kong AI Gateway product page, or check out the Kong + AWS partnership hub at https://konghq.com/partners/aws to learn more.
In this blog post, we'll talk about the significant challenge of managing and governing a growing number of APIs across multiple teams in an organization — and how Control Plane Groups are a clear solution to avoid the chaos of inconsistent policies
Meet Emily. She’s an API product manager at ACME, Inc., an ecommerce company that runs on dozens of APIs. One morning, her team lead asks a simple question: “Who’s our top API consumer, and which of your APIs are causing the most issues right now?”
Ever feel like you're fighting an uphill battle with your API strategy? You're building APIs faster than ever, but somehow everything feels harder. Wasn’t API-first supposed to make all this easier? Well, you're not alone. And now industry analys
The healthcare industry is buzzing about FHIR (Fast Healthcare Interoperability Resources). Pronounced “fire,” this widely adopted data standard has been revolutionizing how healthcare information is exchanged. But building a truly modern, secure, a
Behind every smooth user experience is a maze of APIs quietly handling requests, responses, and data flows. This makes APIs critical connectors that enable applications to communicate and share data seamlessly. When these vital conduits fail, the
As enterprises increasingly embed AI and Large Language Models (LLMs) into their digital experiences, enforcing robust AI guardrails becomes paramount to safeguard users, protect data, manage operational costs, and comply with regulatory and ethical