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

Start in google/adk/integrations/agent_registry/agent_registry.py at AgentRegistry.get_mcp_toolset() and trace how AgentRegistrySingleMcpToolset.get_tools() sets the destination metadata. Compare the response's mcpServerId with attributes["agentregistry.googleapis.com/system/RuntimeReference"]["uri"], then verify that execute_tool spans carry the resource-name URI expected by the Agent Platform Topology matcher.

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%)