debug

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core behavior (symbolication with matching dSYM UUIDs) but does not disclose prerequisites (e.g., that a dSYM must be available), side effects (none apparent), or what happens on failure. It also omits that only one action ('symbols') is supported, though this is inferable from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences. The first front-loads the main purpose; the second delivers scoped exclusions. Every word earns its place with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 28 parameters, no output schema, and two required params, the description adequately scopes the tool and names sibling alternatives. However, it does not state that the 'action' parameter must be set to 'symbols' or clarify that symbolication is a read-only analysis, which would be helpful for a tool with this many generic parameters. The schema compensates partially, so a 4 is warranted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 96%, meaning the input schema already documents parameters in detail. The description adds no additional param-level meaning beyond the mention of 'matching dSYM UUIDs,' which hints at dsym/searchPath but doesn't explain their syntax or specific roles. The baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: 'Symbolicate Apple crash artifacts with matching dSYM UUIDs.' It also differentiates from sibling tools by explicitly naming alternatives (logs, network, perf, record/trace, react-devtools), making the tool's unique scope unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use and when-not-to-use guidance: 'This debug namespace is intentionally narrow: use logs for app logs, network for HTTP evidence, perf for performance samples, record/trace for media and traces, and react-devtools for React Native profiles.' This directly tells the agent which alternatives to choose for other debugging tasks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.