fix(telemetry): added mcp tracing context propagation

[poshinchen]

Description

Add mechanism to attach otel context into mcp _meta and pass along to the tools.

After the change, the traces of the mcp calls are grouped given the parent request is the same.

Related Issues

N/A

Documentation PR

N/A

Type of Change

Bug fix

Testing

How have you tested the change? Verify that the changes do not break functionality or introduce warnings in consuming repositories: agents-docs, agents-tools, agents-cli

• I ran hatch run prepare

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[jer96]

hi @poshinchen after taking a look at modelcontextprotocol/modelcontextprotocol#246, i'm having a bit of trouble understanding exactly what this PR is doing. many of the implementations that were linked to the MCP issue seem to be much simpler:

• feat(llmobs): distributed tracing for mcp DataDog/dd-trace-py#14045
• Propagate Trace Context to MCP SSE Servers lastmile-ai/mcp-agent#241

based on my understanding there are two main features

1. trace context is propagated from client -> server. it seems like this is handled by updating the _meta field with the necessary context
2. emitting spans for MCP client invocations for Strands agents. the implementation here feels like it would be akin to the other manual instrumentation we already do in Strands for things like model invocations and standard tool calls.

can you help shed some light on the added complexity in this PR?