### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement When OTEL tracing is enabled (beta), `claude_code.tool` spans for Skill and Agent tool invocations only include the generic `tool_name` (e.g., `"Skill"` or `"Agent"`). The specific skill being invoked (e.g., `"compose-

[FEATURE] claude_code.tool spans don't identify which skill or agent was invoked

Status Fixed / completed

Maintainer reply None cached

Activity 6 comments · opened Apr 16, 2026 · closed Apr 17, 2026

Preflight Checklist

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

Problem Statement

When OTEL tracing is enabled (beta), claude_code.tool spans for Skill and Agent tool invocations only include the generic tool_name (e.g., "Skill" or "Agent"). The specific skill being invoked (e.g., "compose-render", "direct-creative-brief") is not present on the span.

The corresponding claude_code.tool_result log records do include the specific name via tool_parameters and tool_input attributes, but log records do not carry traceId or spanId, so they cannot be linked back to their span.

Current span attributes:

{
  "span.type": "tool",
  "tool_name": "Skill",
  "duration_ms": 6
}

Proposed Solution

Resolve tool_name to the actual skill/agent name instead of the generic wrapper name (e.g., "fix-docs" instead of "Skill").

Alternative Solutions

_No response_

Priority

Critical - Blocking my work

Feature Category

Developer tools/SDK

Use Case Example

When building an observability dashboard over Claude Code sessions (e.g., tracking which skills are used most, measuring per-skill latency, building operation DAGs), the span tree is the natural data source it provides timing, parent-child relationships, and trace context.

However, with tool_name: "Skill" on every skill span, it is not possible to break down metrics by actual skill without falling back to log records, which lack trace linkage.

Additional Context

_No response_

View original on GitHub ↗

6 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

0xbrainkid · 4 months ago

claude_code.tool spans not identifying which skill or agent was invoked is a critical observability gap for multi-skill and multi-agent deployments — without this, traces show "a tool was called" but not "which tool, by which agent, in which skill context," making them nearly useless for debugging complex agent pipelines.

From an agent identity and behavioral trust perspective, the span identity gap is the same problem as the team agent tab UI gap (#48910 host identity) and the unnamed session problem (#48753 name lost after compaction) — in all cases, the agent's identity is present in the system but not surfaced where it is needed.

Minimum required span attributes for claude_code.tool:

claude_code.tool.name         # which tool was called
claude_code.tool.skill_name   # which skill invoked it (if applicable)  
claude_code.tool.agent_id     # which agent session made the call
claude_code.tool.session_id   # current session identifier
claude_code.tool.invocation   # skill invocation context (if applicable)

With these attributes, a trace shows: "session abc123, running skill code-review, agent opus-agent-1, called tool Bash with args [...]." That is a meaningful behavioral record.

The claude_code.tool.skill_name is particularly important for debugging: when a tool call fails inside a skill, knowing which skill was active at the time of the failure is the first step in diagnosing whether the failure is in the skill itself or in the tool implementation.

This also enables skill-level cost attribution — GROUP BY claude_code.tool.skill_name on your traces gives you cost per skill, which is essential for optimizing complex agent deployments.

authora-aria · 4 months ago

The missing piece is probably span attributes, not new span types. claude_code.tool should carry something like claude.skill.name, claude.agent.name, and maybe claude.invocation.kind=skill|agent|mcp, so downstream OTEL backends can group tool calls without parsing prompt text. If those are only known at dispatch time, attaching them where the tool/skill router resolves the target is enough; OTEL semantic conventions are fine with vendor-prefixed attrs when there isn’t a standard field yet.

It’d also help to set the span name to the resolved target when possible, e.g. claude_code.tool:search_codebase instead of a generic tool span, while keeping the generic operation in an attribute for stable dashboards. That gives both readable traces and low-cardinality aggregation. This would make systems like PeKG much better at linking traces back to the exact skill/agent behavior that produced a decision or memory write.

Alexk2309 · 4 months ago

Hey @mhegazy, I noticed you marked this GitHub issue as completed. Can I assume it has been implemented? If so, do you know which release it will be included in?