check_feasibility

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

Annotations already declare a safe read-only, closed-world operation, and the description goes well beyond them: it discloses the 'feasible' boolean and 'max_achievable_display' return semantics, plus a refusal protocol and a presentation rule (never surface or convert millisecond figures). That is real behavioral context an agent could not infer from readOnlyHint alone.

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?

Front-loaded with the core purpose and the sequencing rule, and most sentences add distinct policy. The refusal paragraph slightly over-enumerates ('do not build a playlist anyway, do not relax the constraint yourself, and do not try alternative track combinations'), which are three phrasings of one instruction.

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 six-parameter, no-output-schema tool the usage and refusal policy are complete, but the description omits any explanation of the parameter formats an agent must supply, which is the main remaining risk. It explains two return fields but not the full result shape.

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 six parameters, yet it never explains any of them. It is ambiguous whether released_after/released_before are years or epoch timestamps, and units for max_track_duration_ms and min_total_duration_ms are only obliquely implied by the millisecond warning.

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?

States a specific verb and resource ('check whether a playlist brief is possible') and positions it temporally ahead of track selection, which distinguishes it from query_library and validate_playlist. An agent knows immediately that this is a pre-flight gate, not a builder or validator.

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?

Explicit when-to-call ('first, before query_library, whenever the user asks for a playlist with constraints'), explicit when-not ('a brief with no constraints at all cannot be checked — ask them before calling'), and explicit failure behavior ('tell the user which constraint fails and stop', 'do not relax the constraint yourself'). Alternatives and exclusions are both covered.

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