Tool discovery for AI agents

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:

• New tools are constantly added
• Tools evolve independently
• Different environments expose different capabilities
• Agents should not need redeployment every time a new tool appears

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.

Introducing the MCP Registry in Kong Konnect

Located natively within the Kong Konnect Catalog menu, the MCP Registry provides a centralized hub to register both local and remote MCP servers.

• Group and Organize: You can create one or several registries to group your MCP servers based on specific metadata.
• Independent Access Control: This grouping enables you to handle servers independently and provide different access levels.
• Standardized Implementation: The registry implements a REST API built in accordance with the specification from the Agentic AI Foundation’s (AAIF) official MCP registry, ensuring long-term compatibility with the MCP ecosystem.

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:

• Environment (development, staging, production)
• Domain capabilities
• Access boundaries
• Team ownership

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.

Enable MCP Registries in Catalog

MCP Registries in Catalog are currently available in [Technical Preview](https://developer.konghq.com/stages-of-software-availability/#tech-preview)Technical Preview via Konnect Labs.

1. In the Konnect sidebar, navigate to Organizations.
2. In the Organization sidebar, click Labs.
3. Click Catalog - MCP Registry.
4. Click the toggle at the top right to enable the integration.

You can access the MCP Registry by navigating to Catalog > MCP Registries in the sidebar.

Registering MCP servers

Within a registry, each MCP server is registered with comprehensive details, including:

• Name
• Description
• Endpoint URL
• Namespace
• Version
• Execution context (remote or local)

These MCP servers may be deployed in various environments:

• Locally
• On remote infrastructure
• On serverless gateways
• Behind API gateways

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.

Querying the registry programmatically

The MCP Registry exposes a REST API that implements the official [MCP Registry OpenAPI specification](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/api/openapi.yaml)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:

• Query available MCP servers
• Search based on metadata
• Retrieve connection details
• Integrate registry discovery into agent workflows

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:

• Name
• Description
• Endpoint
• Namespace

This information allows agents to dynamically select the right tool.

Building an agent that uses the MCP Registry

To illustrate the power of this architecture, consider an AI agent built using the [Volcano agent framework](https://www.volcano.dev/)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:

1. Search: It receives a user prompt and queries the registry to find MCP servers capable of handling that specific request.
2. Execute: If a server is found, the agent parses the returned URL dynamically configures the MCP server, and executes the necessary action to process the prompt.

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.

The workflow in action

Let's look at how this dynamic discovery handles different scenarios based on the available tools in the registry.

Scenario 1: Executing an Available Tool

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.

Scenario 2: Handling Missing Capabilities

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.

Scenario 3: Dynamically Adding New MCP Servers

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:

• Name: Weather MCP
• Namespace: weather
• Description: Get weather for a city
• Endpoint: weather MCP service
• API: OpenWeather API v2.5

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.

1. The agent queries the registry
2. It finds a matching weather MCP server
3. The server URL is returned
4. The agent executes the weather tool

The final response contains real weather data, including:

• Temperature
• Units
• Weather conditions (for example, broken clouds)

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.

Start building discoverable agent architectures

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.

Get started today

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.