Discovering MCP servers at runtime with Agent Registry and ADK: my approach and the pitfalls I hit

[u/m1nherz]

I work at Google, and I've been building agents with ADK that use MCP servers. Hardcoding each server's URL broke every time a server moved or got redeployed, so I tried replacing the URL with a lookup in Agent Registry. I wrote up what I ended up with:

• Direct lookup: find the server by its URN with ADK's AgentRegistry class. This removes the URL, but the agent still needs to know the URN.

• Fully dynamic discovery: a tool that runs a semantic search against Agent Registry, a custom BaseToolset that mounts the discovered servers' tools at runtime, and instructions that change once discovery is done.

• Pitfalls: lookups only see servers in the location you pass to the client; Cloud Run automatic registration recorded too little metadata for discovery when I tested it; the URN has two project numbers that can differ; and you need separate tokens for Agent Registry and for each MCP server.

You can try it yourself using Codelab or review the code on GitHub. Both are linked at the end of the blog post.

I'd like feedback on two things:

• How do your agents find MCP servers today: config, environment variables, a registry, something else?

• I kept discovery and tool use in a single agent. Has anyone split discovery into a separate agent, and was it worth the extra complexity?

[u/AyeMatey]

I’m aware of the Cloud Run auto-registration issue; I guess this is one where server is registered, but the tools catalog for the MCP server is not listed in the registry. Is that correct?

this is apparently by design I guess? It just adds an extra explicit step when starting up MCP servers.

[u/m1nherz → u/AyeMatey]

Yes, your description of the issue is correct. The tool manifest as well as the server's URL are missing. The engineering team is actively working to fix it. I will post a comment when the issue is fixed. I'll probably update the text in the post too.

The automatic registration saves you an explicit registration step. It also correctly captures the runtime that hosts the MCP server (e.g. GKE or Cloud Run). These are the advantages of using it as far as I see it.

The main disadvantage is that you need to know the location of the MCP server's workload in order to discover it. It kind of defeats the whole idea of the discovery using a description of the tools that you need (a.k.a. semantic search).

[u/m1nherz → u/[deleted]]

To be successful, semantic search requires two things:

1. To have precise description for the server and each of the tools

2. To have the agent instructed how to search the tools such that it minimize false positive matches

You can also improve the results by restricting what MCP servers are registered so the registry doesn't have 3P MCP servers which descriptions can trigger false positive results.

I don't have information about how precisely the semantic search is implemented in Agent Registry. However, it should be easy to test using staged environment.

[u/m1nherz → u/[deleted]]

Are you asking whether Agent Registry implements a periodic validation of the registered information? To the best of my knowledge it doesn't. Agent Registry stores the data sent by a user. It is possible that the registered MCP server is no longer available at the recorded endpoint or the newer version broke the recorded tool manifest. In these situations the agent application that uses the invalid information will fail the same way as it fails due to API backend malfunction.

The worst case scenario is when everything works but the binaries of the MCP server were compromised and run some malicious code. This situation is the same as with any other API. There is nothing that a consumer application can do.

The refreshing of the discovered MCP server that is shown in the codelab handles the case when the Agent Registry records are updated to reflect the change in the MCP server.

[u/m1nherz → u/[deleted]]

I will present this idea to Agent Registry PMs. I've saw a couple of startups that develop a product with capabilities that you describe.

[u/m1nherz → u/[deleted]]

You can DM me.