…._onrequest and McpServer.executeToolHandler

- Add orchestrion rewriter entries for Protocol._onrequest (Sync) and McpServer.executeToolHandler (Async)
  in both CJS (dist/cjs) and ESM (dist/esm) paths
- Add McpServerRequestPlugin: creates mcp.server.request span for every incoming JSON-RPC request,
  extracting trace context from HTTP transport headers when available
- Add McpServerToolCallPlugin: creates mcp.server.tool.call child span for tool executions,
  marking isError results as errors
- Fix span lifecycle: use end() (not finish()) for Sync orchestrion hooks, which emit start/end
  events rather than start/finish
- Add server-side test assertions for both new span types across two SDK versions

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

…cycle comment, and add context propagation test

- McpServerToolCallPlugin: RegisteredTool objects have no .name property — the
  name is the key in McpServer._registeredTools. Look up by reference via ctx.self
  so mcp.server.tool.call spans now have the correct resource tag (was undefined).

- McpServerRequestPlugin: document why kind:'Sync'/end() is intentional.
  Protocol._onrequest is fire-and-forget (returns void, schedules async work
  internally). Async kind would await undefined and resolve immediately — same
  lifecycle problem. The span represents "request received" not "request completed";
  mcp.server.tool.call on executeToolHandler covers the meaningful duration.
  Add matching comment to the rewriter config entry.

- setIsErrorTag: extract shared module-level helper used by both McpToolCallPlugin
  and McpServerToolCallPlugin (no functional change; already deduplicated).

- Tests: add context propagation test asserting mcp.server.request is a child of
  mcp.client.tool.call when using InMemoryTransport (same process, async context
  propagates naturally). Use single assertSomeTraces callback so both span IDs are
  captured from the same trace payload. Also assert resource:'test-tool' on the
  mcp.server.tool.call happy path test to cover the name-extraction fix.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

…for full-lifecycle server request spans

Protocol._onrequest is fire-and-forget: it returns void and schedules all async
work via an internal Promise chain. Using kind:'Sync' ended the span immediately
on return, before any handler ran; kind:'Async' was equally wrong (awaiting
undefined resolves instantly).

Replace with shimmer.wrap on Protocol.prototype._onrequest:
- Publish apm:mcp:server:request:start via runStores to establish async context
  for the full Promise chain (enabling correct parent-child relationships)
- Intercept _requestHandlerAbortControllers.delete (called in .finally()) to
  publish apm:mcp:server:request:finish when the chain fully completes

Update McpServerRequestPlugin to subscribe to the new channels instead of the
orchestrion prefix, and use the finish event to close the span.

Remove the four _onrequest entries (ESM+CJS) from the orchestrion rewriter config.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

…, trim comments

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

…t hook

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

…d and transport disconnect

Two bugs identified by Codex review:

1. When the SDK has no registered handler for a method, _onrequest() sends
   MethodNotFound and returns without creating an AbortController. Previously, the
   pending context was recorded before calling original(), so those spans leaked.
   Fix: after calling original(), check whether the SDK registered a controller for
   this request.id — if not, publish finish immediately.

2. When a transport disconnects with in-flight requests, _onclose() calls
   _requestHandlerAbortControllers.clear(), bypassing the wrapped delete().
   Fix: also wrap clear() on the map to publish finish for all pending contexts.

Tests added for both paths.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

…hod-specific tags

Add resource/name/uri/args/response tags to mcp.server.request spans:
- tools/call: mcp.tool.name, mcp.request.arguments, mcp.tool.response
- tools/list: mcp.tool.names
- resources/read: mcp.resource.uri
- resources/list: mcp.resource.uris
- prompts/get: mcp.prompt.name, mcp.request.arguments
- prompts/list: mcp.prompt.names, mcp.prompt.descriptions

Replace INTERNAL_METHODS denylist with an allowlist regex
(^(?:tools|resources|prompts)\/) so unknown future methods
(ping, initialize, tasks/*, sampling/*, etc.) are silently
skipped rather than requiring an explicit exclusion list.

Use a WeakMap (toolNames) for O(1) tool name lookup in
McpServerToolCallPlugin instead of a linear _registeredTools scan.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

…helpers, clarify tool name lookup

- Replace bare diagnostic channels with tracingChannel('apm:mcp:server:request')
  so the instrumentation follows the same convention as undici and other plugins;
  update McpServerRequestPlugin prefix to 'tracing:apm:mcp:server:request' and
  rename finish() → asyncEnd() to match TracingChannel semantics
- Extract tagRequestParams / tagRequestResult helpers in tracing.js to remove
  inline tag logic from bindStart / asyncEnd
- Add comment on _createRegisteredTool shimmer explaining it populates toolNames
  WeakMap in tracing.js for O(1) resource tag on McpServerToolCallPlugin spans

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

…t span coverage

Introduce McpPlugin base class so each plugin only declares static id/prefix/
spanName/kind and overrides getResource/onStart/onEnd — eliminating duplicated
bindStart/asyncEnd boilerplate across all four plugins.

Add client-side spans for the remaining MCP operations that previously had none:
- mcp.resources.list  (Client.listResources)
- mcp.resource.read   (Client.readResource,  resource = URI)
- mcp.prompts.list    (Client.listPrompts)
- mcp.prompt.get      (Client.getPrompt,     resource = prompt name)

Expand orchestrion rewriter config to use helper functions instead of repeating
the ESM/CJS entry pair for every method; add the four new client methods and
keep the existing server entry.

Fix: use dc-polyfill channel instead of diagnostics_channel directly.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

…lkit/modelcontextprotocol-sdk/server-tracing

…ol-sdk/server-tracing