MCP servers in Catalog

Related Documentation
Incompatible with
on-prem

As teams build MCP servers for AI agents, those servers are often embedded directly in agent code, defined in local configuration files, or scattered across repositories, with no shared record of what already exists. Catalog gives you a single place to see every MCP server across your organization, so you don’t have to track each one down in a separate tool to know what it does or how to connect to it. An MCP server is an interface in Catalog that represents an MCP server your organization builds or consumes.

You can create an MCP server in Catalog in a few ways:

  • Define it manually, filling out its details yourself.
  • Paste an existing server’s JSON definition.
  • Import it from AI Gateway 2.0, by linking an existing AI Gateway MCP server as the source.
  • (Coming soon) Connect to a running MCP server, and have Konnect fetch its definition directly.

When an MCP server is linked to AI Gateway 2.0, the link indicates that AI Gateway is protecting and proxying that server. An MCP server that isn’t linked can still exist in Catalog as part of your organization’s inventory. The absence of a link can also help you identify MCP servers that aren’t yet protected by AI Gateway and could be candidates to govern with it.

The link is a snapshot, not a live sync: if you change the linked server’s configuration in AI Gateway, the MCP server in Catalog isn’t automatically updated to match.

Create an MCP server

FAQs

If you’re creating a new MCP definition, create an MCP server. It’s the preferred object going forward, and is additive to the MCP registry’s server object. It captures remotes and packages like an MCP registry, but also supports the server’s tools, resources, and prompts. You can also link an MCP server to AI Gateway 2.0 as its source.

If you’re already using MCP registries, we recommend migrating to MCP server so you can use these additional capabilities. You can automate this by writing a script that iterates through each MCP registry and the MCP servers nested under it, then creates a new MCP server using the new object model for each one, including its remotes and packages. You won’t lose any information in the process, since the new object model is additive.

Help us make these docs great!

Kong Developer docs are open source. If you find these useful and want to make them better, contribute today!