google / google/adk-python

Enhanced Distributed Tracing for External MCP Calls

Offen
#3,063 2 Kommentare 1 Reaktion 2 zugewiesene Personen Beansprucht von @klateefa Auf GitHub ansehen
mcp needs review tracing
Vorherrschende Sprache
Python
Sterne
21.5k
Forks
4k
Ø Merge
1 T. 14 Std.
Gemergte PRs (30 T.)
37

Beschreibung

**Please make sure you read the contribution guide and file the issues in the right place.**
[Contribution guide.](https://google.github.io/adk-docs/contributing-guide/)

**Is your feature request related to a problem? Please describe.**
I am unable to effectively monitor and debug the latency of external services invoked by an ADK agent using the Model Context Protocol.

When an agent calls a remote tool (e.g., `execute_tool_echo`), the trace only shows a span for the ADK internal execution step (`execute_tool_echo`). It fails to generate a downstream child span that represents the actual outbound HTTP/RPC request to the external MCP server endpoint.

**Describe the solution you'd like**
I would like the ADK's MCP client implementation to ensure full distributed tracing visibility when making calls to external MCP servers.

Specifically, the ADK framework should guarantee the following for every outbound MCP network request:

1. Span Creation: A dedicated child span must be created immediately before the network request is initiated. This span should accurately reflect the client-side call to the external tool service and be a direct child of the current `execute_tool_[tool_name]` span.
2. Dependency Identification: The new span must be annotated with standard telemetry attributes (metadata) required to identify the external service being called (e.g., service address and request URL) to enable accurate dependency mapping in APM systems.
3. Context Propagation: The ADK client must reliably propagate the active OpenTelemetry trace context by injecting the required headers into the outbound MCP request, allowing the remote MCP server to continue the trace correctly.

**Describe alternatives you've considered**
I have attempted to solve this using programmatic instrumentation by installing and enabling all common OpenTelemetry client instrumentors:
- opentelemetry-instrumentation-requests
- opentelemetry-instrumentation-httpx
- opentelemetry-instrumentation-urllib3
- opentelemetry-instrumentation-urllib
- opentelemetry-instrumentation-grpc
- opentelemetry-instrumentation-aiohttp-client

**Additional context**
Full distributed tracing for external MCP calls fundamentally transforms the agent's performance troubleshooting workflow. Currently, developers face a frustrating "black box" scenario, where tool execution time is visible (`execute_tool_echo`), but the cause of that delay (network, external service processing) is hidden. Implementing this feature would allow for immediate root-cause analysis, providing clear, visual confirmation of where bottlenecks lie.

Beitragsleitfaden

Beitragsleitfaden öffnen

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.