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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructive=false, so the safety profile is covered. The description adds behavioral detail beyond annotations by specifying the output decomposition (individual builds with labels, descriptions, fully decoded skill bars) and the whitespace tolerance. There is no contradiction between description and annotations.

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 three focused sentences: purpose and output in the first, input tolerance in the second, and alternative routing in the third. Every sentence carries information and is front-loaded with the core definition. No redundant phrasing exists.

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?

For a one-parameter, read-only decode tool with an output schema and safe annotations, the description covers the input format, the output breakdown, whitespace tolerance, and the sibling distinction. The agent has everything needed to invoke it correctly. The output schema and sibling list supply the remaining integration context.

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 100% – the schema already explains the 'pwnd' parameter as 'The full pwnd blob, starting with pwnd000'. The description adds context about the source format ('shared on PvXwiki team pages') and whitespace tolerance, but does not significantly expand the parameter's meaning. Per the high-coverage baseline, 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 states a specific verb and resource: 'Decode a paw-ned2 team build blob' and spells out what the output is ('player/hero label, description, and each skill bar fully decoded'). It explicitly differs from the sibling decode_template by naming the non-team case. There is no ambiguity about what this tool does.

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 explicitly tells the agent when to use this tool ('team build blob') and when not to ('For a single (non-team) build code, use decode_template instead'), naming the alternative. It also states that whitespace and line wraps are tolerated, which is practical input guidance. This is clear when-to-use and when-not guidance.

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