summarize_library

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

No annotations are provided, so the description carries full burden. The health/counts/stats framing implies a read-only analysis, but it never explicitly states that it has no side effects, or whether it consumes significant API time/budget in the presence of get_api_limits/get_search_budget siblings. It does disclose what data it examines, which is useful.

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?

One dense purpose line plus a short directive sentence, with the headline information front-loaded and zero filler (there is a typo, but structurally it's tight).

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 zero-parameter analysis tool, the description adequately covers inputs (none), analysis scope (which checks), and when to run it (before reorganisation). It leaves the return format and potential cost underscored, but these are minor given the simplicity of the invocation surface.

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?

With zero parameters and 100% schema coverage, the description need not document inputs. The 'whole-library' framing still adds the implicit meaning of what the analysis rangers over, so it adds value even though there are no inputs to explain.

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 opens with a clear subject ('Whole-library health') and then lists the specific categories covered, giving the agent a concrete idea of its outputs. The 'whole-library' scoping distinguishes it from sibling tools like summarize_playlist, dedupe_report, and playlist_diff even though those aren't explicitly named.

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?

'Use before any reorganisation' is a direct and actionable when-to-use directive. It doesn't list alternatives or exclusions by name (e.g., when to prefer summarize_playlist), but the scoping already implies those boundaries.

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