[FEATURE] Emit mcp.server_name and mcp.tool_name as first-class OTEL attributes

Problem Statement

When Claude Code's OpenTelemetry export is enabled (CLAUDE_CODE_ENABLE_TELEMETRY=1), MCP tool calls are only distinguishable by parsing the tool_name attribute, which carries the composite string mcp__<server>__<tool>. There is no discrete mcp.server_name / mcp.tool_name attribute on the emitted telemetry.

Enterprises governing MCP usage need to answer "which MCP servers are connected, by whom, and which are unapproved" directly from telemetry. Today that requires every adopter to write a string-splitting transform in their OTEL Collector to recover server and tool from tool_name. That works, but:

• It is brittle: it depends on the mcp__<server>__<tool> naming convention staying stable, and on __ never appearing inside a server or tool name.
• It pushes identical boilerplate into every deployment.
• It is invisible to anyone reading the raw telemetry without the transform.

Proposed Solution

Emit the MCP server and tool as their own OTEL attributes on tool-call records (and on spans, if/when tool calls are exported as spans), alongside the existing tool_name:

• mcp.server_name — the server identifier (the part between mcp__ and the second __)
• mcp.tool_name — the tool identifier

Following OTel semantic-convention style (dotted namespacing) keeps it consistent with the existing user.* attributes. First-class attributes would make per-server dashboards, classification, and "unknown server" alerting work directly off the exported signal, with no client-side string parsing.

Alternative Solutions

A downstream OTEL Collector transform that splits tool_name on __ into mcp.server_name / mcp.tool_name. Functional, but brittle and duplicated across every deployment, as described above. A PreToolUse hook that logs MCP calls is another workaround, but it lives outside the telemetry pipeline.

Additional Context

Raised while building MCP visibility on the collector side for an OpenTelemetry-based deployment. The string-parsing workaround is functional; this request is the upstream fix that would make it unnecessary, since the server/tool split is information the client already has.

---
_Preflight: searched existing requests (open and closed) for mcp.server_name, MCP telemetry attributes, and OTEL MCP visibility — no existing request for native MCP server/tool attributes. Closest existing issues (#32364 OTEL on web, #66199 traceparent injection) cover different asks._