Repository navigation
AgentRegistry.get_mcp_toolset() reads the wrong field for gcp.mcp.server.destination.id — breaks Agent Platform Topology view #7196
Description
AgentRegistry.get_mcp_toolset() populates the gcp.mcp.server.destination.id span attribute (used to associate an execute_tool span with its destination MCP server for App Hub / Agent Platform Topology matching) from the Agent Registry API's mcpServerId field — a urn:mcp:... value.
The Agent Platform Topology view's connection matcher expects the App Hub resource-name URI form instead (//agentregistry.googleapis.com/projects/<number>/locations/<region>/services/<name>), which is present, unused, in the very same API response under attributes["agentregistry.googleapis.com/system/RuntimeReference"]["uri"].
As a result, no topology connection is ever drawn for an MCP server reached through AgentRegistry/AgentRegistrySingleMcpToolset, regardless of correct registration, functional type, or App Hub configuration — the span's destination identifier never matches the App Hub inventory's own identifier form for that same resource.
Steps to Reproduce:
- Register an MCP server with Agent Registry and build an
McpToolsetfor it viaAgentRegistry.get_mcp_toolset(mcp_server_name). - Have an ADK agent call a tool from that toolset, with tracing enabled (
--otel_to_cloud, OTLP export totelemetry.googleapis.com). - Inspect the resulting
execute_toolspan'sgcp.mcp.server.destination.idattribute — it is the Agent Registry API'smcpServerIdvalue, aurn:mcp:projects-<number>:projects:<number>:locations:<region>:agentregistry:services:<name>string. - Separately,
GETthe same MCP server resource from the Agent Registry API directly (.../v1/projects/<number>/locations/<region>/mcpServers/<id>) and comparemcpServerIdagainstattributes["agentregistry.googleapis.com/system/RuntimeReference"]["uri"]in the same response — the two differ in form. - Open the Agent Platform console's Topology view for the calling agent — no connection is drawn to the MCP server, even with App Hub discovery, functional types, and registration otherwise correct.
Expected Behavior:
gcp.mcp.server.destination.id should be set to the App Hub resource-name URI (RuntimeReference.uri), so the Agent Platform Topology view's connection matcher can resolve it against its own discovered-resource inventory and draw the connection.
Observed Behavior:
The attribute is set to mcpServerId (a urn:mcp:... value) instead, which never matches App Hub's inventory. The Topology view draws no connection to the MCP server.
Confirmed by hand-crafted OpenTelemetry traces sent through the same OTLP-to-telemetry.googleapis.com export path ADK's own agents use: a trace with the real urn:mcp:... value produces no connection; the identical trace with only that attribute rewritten to the RuntimeReference.uri form produces one immediately. Confirmed independently on two separate, previously-untested MCP servers, changing only that one attribute.
Environment Details:
- ADK Library Version (
pip show google-adk): reproduced on2.7.0and2.9.2(latest at time of writing) — identical behavior in both - Desktop OS: N/A — server-side library behavior, not OS-dependent
- Python Version (
python -V):3.11(deployment container); also reproduced against the library installed under Python 3.14 in an isolated verification environment
Model Information:
- Are you using LiteLLM: No
- Which model is being used: N/A — bug is in the Agent Registry / tracing integration, independent of model
Regression:
Not established — reproduces identically on both 2.7.0 and the current latest (2.9.2), so not a recent regression as far as tested.
Additional Context:
The Agent Registry API returns both identifiers in the same object, which is what makes this a precise, one-field fix rather than a missing-data problem:
{
"mcpServerId": "urn:mcp:projects-<number>:projects:<number>:locations:<region>:agentregistry:services:<name>",
"attributes": {
"agentregistry.googleapis.com/system/RuntimeReference": {
"uri": "//agentregistry.googleapis.com/projects/<number>/locations/<region>/services/<name>"
}
}
}Relevant source (unchanged between 2.7.0 and 2.9.2, only line numbers shift):
google/adk/integrations/agent_registry/agent_registry.py,AgentRegistry.get_mcp_toolset(): readsmcp_server_id = server_details.get("mcpServerId")and passes it verbatim asdestination_resource_idintoAgentRegistrySingleMcpToolset.- Same file,
AgentRegistrySingleMcpToolset.get_tools(): stampstool.custom_metadata["gcp.mcp.server.destination.id"] = self.destination_resource_idon every tool. google/adk/telemetry/tracing.py,trace_tool_call(): copies that value verbatim onto theexecute_toolspan, with an in-source comment: "Used to associate a span with a destination resource for AppHub."
Suggested fix: source destination_resource_id from server_details["attributes"]["agentregistry.googleapis.com/system/RuntimeReference"]["uri"] instead of (or in preference to) mcpServerId.
How often has this issue occurred?:
- Always (100%)
Activity
chelsealong commentedon Sep 18, 2026
Picking this one up now — opening a PR shortly. Flagging it here so nobody duplicates the work; if someone is already on it, say so and I will drop mine.
llalitkumarrr commentedon Sep 24, 2026
Hello @pib,
Thanks for the report. We reproduced this on
2.9.2with a self-registered Cloud Run MCP server,RuntimeReference.uriis in the registry record butgcp.mcp.server.destination.idis set tomcpServerId(urn:mcp:...).We also tested with PR #7197 and it should the reported issue, ADK now uses
RuntimeReference.uriand falls back tomcpServerIdfor Google managed servers.Please note that this PR still requires a detailed review and approval before it can be merged. We appreciate your patience in the meantime. Additionally could you please test the PR and let us know your inputs as well?
adk-bot commentedon Oct 2, 2026
This issue has been automatically marked as stale because it has not had recent activity for 7 days after a maintainer requested clarification. It will be closed if no further activity occurs within 7 days.
adk-bot commentedon Oct 7, 2026
This issue has been automatically marked as stale because it has not had recent activity for 7 days after a maintainer requested clarification. It will be closed if no further activity occurs within 7 days.
pib commentedon Oct 12, 2026
I have tested it and it works as expected. I am getting the correct ID in traces and seeing the edge in the topology view that I was not seeing before.
fix: source MCP destination ID from RuntimeReference.uri