## Why
MCP requests need to retain inbound W3C trace context even when no OpenTelemetry tracing layer is installed.
## What changed
- Carry validated request trace context through app-server MCP tasks, connection startup, and resource listing tasks, while preferring active span context.
- Forward fallback `traceparent` and `tracestate` headers for MCP HTTP requests, including discovery and initialization.
- Use HTTP trace headers as a fallback for exec-server RPC calls when active span context is unavailable.
## Testing
Add an app-server integration test that disables trace exporting and verifies that `mcpServer/resource/read` forwards the inbound `traceparent` and `tracestate` to the MCP server.
GitOrigin-RevId: c886a55ce0a3992f1b2e04614efec80a20cb4b49
## Why
MCP requests pass through background transport queues, so HTTP requests need the caller's trace context carried explicitly to preserve trace ancestry.
## What changed
- Capture W3C trace context in request metadata for tool and resource operations, custom requests, and event streams.
- Restore that context in an `mcp.http.request` span around HTTP POSTs, linking outgoing HTTP traces to the originating request.
- Preserve application metadata while replacing trace fields with the current caller's context and removing stale `tracestate`. Read the SDK's merged metadata so extension fields retain precedence over parameter metadata.
## Testing
Add a unit test for metadata merge precedence and an integration test covering concurrent paginated requests, tool calls, custom requests, and tool-call continuations across legacy and `2026-07-28` protocol modes. Verify HTTP trace ancestry, metadata preservation, and removal of stale `tracestate`.
GitOrigin-RevId: 0b22cd75f31f9fcb855b27fa8d34ecdffd6e3549
Joe Savona