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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds useful non-schema context: OAuth authentication and a trial or paid plan are required, and each returned node indicates whether it has children. It does not describe error behavior or pagination, but it meaningfully supplements the 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 four tight sentences, front-loading the purpose and then covering parameter usage, node behavior, and access requirements. Every sentence adds actionable information with no filler.

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 simple one-parameter tree traversal tool with annotations covering safety and no output schema, the description covers how to call it, access constraints, and the key child-flag behavior. It stops short of describing the full returned node shape or traversal depth semantics, but an agent has enough to invoke it correctly.

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 0%, so the description carries the full burden for the single `parent` parameter. It explains omission for top-level results, passing a code to list children, accepting the code with or without the check digit, and gives examples such as '45000000-7' and '45000000'. This is substantially more useful than the schema's pattern alone.

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 uses a clear verb plus resource: 'Walk the CPV hierarchy' and explains that it lists children or top-level divisions. It is clearly a different operation from siblings like cpv_search and cpv_labels, but it does not explicitly name or differentiate them, so it falls short of the sibling-routing clarity required for a 5.

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?

It gives concrete usage guidance: omit `parent` for top-level divisions and pass a CPV code to list its children. This is clear enough to invoke correctly, but it does not mention alternatives such as using cpv_search for keyword lookup or cpv_labels for labels.

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