anilist_pick

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

Annotations already mark readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description complements this by explaining the recommendation behavior (taste profile, fallback, filters) without contradicting the annotations. It adds value by detailing process – using the Planning list as primary source and falling back to top-rated titles – which is not evident from annotations 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?

The description is three sentences with zero wasted words. It front-loads the core purpose (first sentence), adds a secondary use case (second sentence), and lists key optional behaviors (third sentence). Every sentence earns its place, achieving maximum efficiency.

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 10 parameters, no output schema, and the tool's recommendation complexity, the description adequately covers use cases, fallback behavior, and optional filters. It mentions return structure ('ranked picks with match score, genre alignment, and mood fit'). A minor gap is not describing what happens with empty results beyond fallback, but overall it is sufficiently complete.

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%, so the baseline is 3. The description does not add new parameter meanings beyond what the schema already provides (e.g., username, type, source, etc.). It contextualizes parameters (e.g., mood as 'freeform vibe') but does not substantially enhance understanding of individual parameters.

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 starts with the user-facing question "What should I watch/read next?" and clearly states it recommends from the Planning list based on taste profile. It distinguishes from sibling tools like anilist_recommendations or anilist_taste by specifying the source (Planning list) and fallback behavior, making its purpose concrete and specific.

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 clear usage context: deciding what to watch/read next from the Planning list, and explicitly mentions it also works for backlog analysis. It lists optional filters (mood, max episodes) and source alternatives (Seasonal, Discover), giving the agent a good sense of when to invoke. However, it does not explicitly exclude other tools or state when not to use this one, missing a perfect score.

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