claude-code - 💡(How to fix) Fix [FEATURE] `tool_result` OTel event: emit classification metadata (`mcp_server_name`, `mcp_tool_name`, `skill_name`, `subagent_type`) unconditionally [3 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#52783Fetched 2026-04-25 06:21:04
View on GitHub
Comments
3
Participants
2
Timeline
7
Reactions
0
Timeline (top)
commented ×3labeled ×3renamed ×1

Error Message

  1. We want a "tool usage by MCP server" dashboard — e.g., how often each MCP server is called, p95 latency per server, error rate per server.
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing requests and this feature hasn't been requested yet
  • This is a single feature request (not multiple features)

Problem Statement

When running Claude Code with OTel enabled for observability, I want to classify tool calls in my telemetry backend by MCP server name, MCP tool name, skill name, and sub-agent type, so I can build per-server latency, per-skill usage frequency, and per-sub-agent duration dashboards.

Today these fields are only emitted in the tool_result OTel event when I set OTEL_LOG_TOOL_DETAILS=1. But that same flag also exports tool_input and tool_parameters.full_command (full Bash command string) to the OTel backend and those routinely carry sensitive data: .env file contents passed to Write, API keys in curl arguments, credentials passed as MCP tool args, etc.

So for every observability deployment I have to choose between "no classification metadata" and "full payload leak". Classification metadata is not sensitive, it's just labels, and shouldn't be coupled to the payload flag.

Proposed Solution

Emit these fields in the tool_result OTel event unconditionally, independent of OTEL_LOG_TOOL_DETAILS:

  • mcp_server_name
  • mcp_tool_name
  • skill_name
  • subagent_type (not emitted at all today)

Keep tool_input, tool_parameters.bash_command, and tool_parameters.full_command gated by OTEL_LOG_TOOL_DETAILS=1 as they are now (they do carry sensitive content).

Alternative Solutions

  • Parsing the full mcp__<server>__<tool> string from tool_name — works for MCP only, fragile, doesn't apply to skills or sub-agents.
  • Enabling OTEL_LOG_TOOL_DETAILS=1 and stripping sensitive fields downstream — data has already been exported, and the stripping is opt-in work per-deployment.
  • Not collecting this telemetry at all — loses material observability value.

Priority

High - Significant impact on productivity

Feature Category

Developer tools/SDK

Use Case Example

  1. Running Claude Code with OTel exporter pointed at our internal Grafana / Loki.
  2. We want a "tool usage by MCP server" dashboard — e.g., how often each MCP server is called, p95 latency per server, error rate per server.
  3. Skill-level analytics: which skills are invoked most, average duration per skill.
  4. Sub-agent analytics: when the agent spawns a sub-agent (Agent / Task tool), group metrics by subagent_type.
  5. All of this needs only the labels; we do not want tool_input or raw Bash commands in our observability pipeline.
  6. Today we can't get (2)–(4) without also ingesting sensitive content, so we skip the dashboards entirely.

Additional Context

  • Symmetric to the duration_ms on PostToolUse / PostToolUseFailure hooks that shipped recently (thanks!) — this is the equivalent split on the OTel side.
  • mcp_server_scope in tool_result is the precedent for what "emit unconditionally" looks like.

extent analysis

TL;DR

Emit classification metadata fields (mcp_server_name, mcp_tool_name, skill_name, subagent_type) in the tool_result OTel event unconditionally, without requiring OTEL_LOG_TOOL_DETAILS=1.

Guidance

  • Review the proposed solution to ensure it meets the requirements for unconditional emission of classification metadata fields.
  • Verify that the sensitive fields (tool_input, tool_parameters.bash_command, tool_parameters.full_command) remain gated by OTEL_LOG_TOOL_DETAILS=1.
  • Consider the alternative solutions and their limitations, such as parsing the tool_name string or enabling OTEL_LOG_TOOL_DETAILS=1 with downstream stripping.
  • Evaluate the impact of this change on existing observability pipelines and dashboards.

Example

No code snippet is provided as the issue does not contain specific code references.

Notes

The solution should be carefully evaluated to ensure it does not introduce any security risks or data leaks. The proposed solution seems to be a reasonable approach, but it requires careful review and testing.

Recommendation

Apply the proposed solution to emit classification metadata fields unconditionally, as it seems to be the most straightforward and effective way to address the issue without compromising sensitive data.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [FEATURE] `tool_result` OTel event: emit classification metadata (`mcp_server_name`, `mcp_tool_name`, `skill_name`, `subagent_type`) unconditionally [3 comments, 2 participants]