Skip to content

AgentRegistry.get_mcp_toolset() reads the wrong field for gcp.mcp.server.destination.id — breaks Agent Platform Topology view #7196

Closed

Description

@pib

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:

  1. Register an MCP server with Agent Registry and build an McpToolset for it via AgentRegistry.get_mcp_toolset(mcp_server_name).
  2. Have an ADK agent call a tool from that toolset, with tracing enabled (--otel_to_cloud, OTLP export to telemetry.googleapis.com).
  3. Inspect the resulting execute_tool span's gcp.mcp.server.destination.id attribute — it is the Agent Registry API's mcpServerId value, a urn:mcp:projects-<number>:projects:<number>:locations:<region>:agentregistry:services:<name> string.
  4. Separately, GET the same MCP server resource from the Agent Registry API directly (.../v1/projects/<number>/locations/<region>/mcpServers/<id>) and compare mcpServerId against attributes["agentregistry.googleapis.com/system/RuntimeReference"]["uri"] in the same response — the two differ in form.
  5. 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 on 2.7.0 and 2.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(): reads mcp_server_id = server_details.get("mcpServerId") and passes it verbatim as destination_resource_id into AgentRegistrySingleMcpToolset.
  • Same file, AgentRegistrySingleMcpToolset.get_tools(): stamps tool.custom_metadata["gcp.mcp.server.destination.id"] = self.destination_resource_id on every tool.
  • google/adk/telemetry/tracing.py, trace_tool_call(): copies that value verbatim onto the execute_tool span, 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

  1. chelsealong commented on Sep 18, 2026

    @chelsealong
    Contributor

    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.

  2. added
    mcp[Component] This issues is related to MCP support
    on Sep 21, 2026
  3. llalitkumarrr commented on Sep 24, 2026

    @llalitkumarrr
    Collaborator

    Hello @pib,

    Thanks for the report. We reproduced this on 2.9.2 with a self-registered Cloud Run MCP server, RuntimeReference.uri is in the registry record but gcp.mcp.server.destination.id is set to mcpServerId (urn:mcp:...).

    We also tested with PR #7197 and it should the reported issue, ADK now uses RuntimeReference.uri and falls back to mcpServerId for 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?

  4. added
    request clarification[Status] The maintainer need clarification or more information from the author
    on Sep 24, 2026
  5. adk-bot commented on Oct 2, 2026

    @adk-bot
    Collaborator

    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.

  6. added
    stale[Status] Issues which have been marked inactive since there is no user response
    on Oct 2, 2026
  7. removed
    stale[Status] Issues which have been marked inactive since there is no user response
    on Oct 7, 2026
  8. adk-bot commented on Oct 7, 2026

    @adk-bot
    Collaborator

    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.

  9. added
    stale[Status] Issues which have been marked inactive since there is no user response
    on Oct 7, 2026
  10. pib commented on Oct 12, 2026

    @pib
    Author

    8. Hello @pib,
    Thanks for the report. We reproduced this on 2.9.2 with a self-registered Cloud Run MCP server, RuntimeReference.uri is in the registry record but gcp.mcp.server.destination.id is set to mcpServerId (urn:mcp:...).
    We also tested with PR #7197 and it should the reported issue, ADK now uses RuntimeReference.uri and falls back to mcpServerId for 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?

    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.

  11. removed
    stale[Status] Issues which have been marked inactive since there is no user response
    on Oct 13, 2026
  12. added a commit that references this issue on Oct 19, 2026
    2802834
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

mcp[Component] This issues is related to MCP supportrequest clarification[Status] The maintainer need clarification or more information from the author

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions