As enterprises start deploying AI agents into real systems, a new architectural challenge is emerging. Agents need a reliable way to discover tools, services, and capabilities dynamically, instead of relying on hardcoded integrations.
This is where the Model Context Protocol (MCP) ecosystem is rapidly evolving. MCP servers expose tools and capabilities that AI agents can use. However, once organizations begin deploying multiple MCP servers across environments, the question becomes clear.
How do agents discover the right MCP server at runtime?
To address this, Kong has launched a new capability that is currently in Tech Preview: Kong MCP Registry in Kong Konnect.
This capability allows developers to dynamically manage how their AI agents discover and consume tools, moving away from rigid, hardcoded configurations to a flexible, programmatic approach.
In this article, we walk through a practical example showing how an AI agent can:
The result is a more scalable pattern for building agentic systems that evolve without redeploying the agent itself.
In early agent implementations, tools are often statically configured inside the agent.
For example:
{
"mcpServers": {
"weatherServer": {
"command": "uv",
"args": [
"run",
"weather_server.py"
]
},
"githubServer": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-github"
]
},
"remoteApiServer": {
"url": "https://api.example.com",
"headers": {
"Authorization": "Bearer sk-xxx"
}
}
}
}
This works for simple prototypes. It breaks down quickly in enterprise environments because:
A better model is dynamic tool discovery.
Instead of embedding tools directly in the agent, agents should be able to ask:
"What tools exist that can help me answer this request?"
This is exactly the role of an MCP registry.
Located natively within the Kong Konnect Catalog menu, the MCP Registry provides a centralized hub to register both local and remote MCP servers.
From the Konnect UI, the MCP Registry appears as a new Catalog entry where users can create and manage registries.
Each registry groups MCP servers based on metadata such as:
This allows organizations to manage MCP services independently while still enabling agent discovery.
For example, a Development MCP Registry may contain experimental tools or only be available for development purposes, while a production registry contains only approved services.
Additionally, instead of manually retrieving server connection details through the UI, applications and agents can query these registries programmatically using the REST API.
MCP Registries in Catalog are currently available in Technical Preview via Konnect Labs.
You can access the MCP Registry by navigating to Catalog > MCP Registries in the sidebar.
Within a registry, each MCP server is registered with comprehensive details, including:
These MCP servers may be deployed in various environments:
The registry confers a straightforward yet substantial advantage:
It establishes the definitive source of truth for agent capabilities.
Consequently, instead of requiring manual configuration, agents interact with the registry to dynamically ascertain their available functions.
The MCP Registry exposes a REST API that implements the official MCP Registry OpenAPI specification, following the standard donated by Anthropic to the Agentic AI Foundation (AAIF) in December 2025. The specification allows flexibility in how registries are structured, so you can model them according to your organization’s governance needs.
This allows developers to:
Instead of navigating the UI, an agent can programmatically call the registry and retrieve the list of services.
For example:
GET /v0.1/servers?search=weather
The response contains structured information about matching MCP servers, including:
This information allows agents to dynamically select the right tool.
To illustrate the power of this architecture, consider an AI agent built using the Volcano agent framework. Rather than hardcoding every possible tool into the agent's logic, the agent is configured with only a single URL: the endpoint for the MCP registry running on a local gateway instance.
The agent operates in a simple two-step flow:
User Prompt
│
▼
Agent Step 1
Search MCP Registry
│
▼
Select Matching MCP Server
│
▼
Agent Step 2
Execute Action Using MCP
│
▼
Return Result
This design separates tool discovery from tool execution, which is a key pattern in scalable agent architectures.
Let's look at how this dynamic discovery handles different scenarios based on the available tools in the registry.
Step 1: Searching for MCP Servers
The agent begins by receiving a prompt.
Example:
Tell me a Chuck Norris joke about history
The agent sends a query to the MCP registry using a structured LLM step. This step returns information in a structured format, such as:
{
name: "Chuck Norris Joke Server",
description: "Generates Chuck Norris jokes",
url: "https://gateway.example.com/mcp/jokes"
}
If no matching server is found, the agent stops.
If a match exists, the workflow proceeds to the next stage.
Step 2: Executing the MCP Action
Once a server is discovered, the agent dynamically configures the MCP connection using the returned server URL.
The agent then executes the action prompt using the selected MCP server.
Example workflow:
Prompt → Find Joke MCP Server
Prompt → Execute Joke Tool
Return Result
The response might look like:
After returning from World War II, Chuck Norris shook hands with history. The rest is history.
This demonstrates how the agent used registry discovery plus tool execution to produce a response.
The system also behaves intelligently when capabilities do not exist.
For example, if a user asks the following:
What is the weather in Tokyo?
Initially, the registry does not contain any weather MCP servers.
The agent queries the registry and finds no matching capability.
The workflow stops with a clear response:
No MCP server found capable of handling this request.
This behavior is important. It prevents hallucinations and ensures the agent only acts when a trusted tool exists.
This is where the registry shines. Without touching the agent's code, we can simply add a new tool to the environment.
We register a weather MCP server with the following metadata:
Once saved and published, this new weather service becomes immediately active on the developer registry. No code changes are required.
Now we run the same prompt again:
What is the weather in Tokyo?
This time, the workflow changes.
The final response contains real weather data, including:
The agent was able to perform a task it previously could not handle, simply because a new MCP server appeared in the registry.
This is the power of dynamic capability discovery.
As AI agents move from experiments into production systems, the architecture around them needs to evolve. Hardcoding tools directly into agents does not scale in environments where services are constantly changing, capabilities are expanding, and governance matters.
The MCP Registry in Kong Konnect introduces a practical solution to this challenge. By centralizing the discovery of MCP servers, teams can give agents a single place to find capabilities at runtime. Agents no longer need to know every tool in advance. Instead, they can query the registry, identify the right service for the task, and execute it dynamically.
If you want to explore this approach further, start by creating an MCP registry in Kong Konnect and registering your first MCP servers. Then build a simple agent that queries the registry and executes one of those tools.
Are you a Kong customer interested in participating in the Kong MCP Registry Tech Preview? To try it, enable it in Konnect Labs and contact your account team with any questions.
Once you see your agent discover and use a capability it did not know about before, you will start to understand the real power of registry-driven agent architectures.
Managed Redis cache is a turnkey "Shared State" add-on for Kong Dedicated Cloud Gateways. It is designed to combine the performance of an in-memory data store with the simplicity of a SaaS product. When you spin up a Dedicated Cloud Gateway in Kong
The Shifting Economic Landscape: The AI token economy in 2026 is evolving, and enterprise leaders must distinguish between low-cost input tokens and high-premium output tokens to maintain profitability. Agentic AI Financial Risks: The transition t
A Response to Gartner’s Latest Research We have crossed a threshold in the AI economy where the competitive advantage is no longer about access to data — it’s about access to context. The "context economy" has arrived, defined by a fundamental
Traditional APIs are, in a word, predictable. You know what you're getting: Compute costs that don't surprise you Traffic patterns that behave themselves Clean, well-defined request and response cycles AI APIs, especially anything that runs on LLMs
The Kong MCP Registry acts as a central directory for AI agents and clients to access services that provide context or take action. For AI agents, think of it as a combination of a "Service Catalog" and a "Developer Portal." It offers the metadata,
Architecture Overview A multicloud DCGW architecture typically contains three main layers. 1\. Konnect Control Plane The SaaS control plane manages configuration, plugins, and policies. All gateways connect securely to this layer. 2\. Dedicated C
Claude Code is Anthropic's agentic coding and agent harness tool. Unlike traditional code-completion assistants that suggest the next line in an editor, Claude Code operates as an autonomous agent that reads entire codebases, edits files across mult