download.fan

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

Annotations already declare readOnly=true, destructive=false, and openWorld=false, so safety is covered. The description earns extra credit by disclosing the shape of the result: up to five pages, each with links — information not present in any structured field. It could still say what happens on zero matches.

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 verb+resource before the category enumeration, and the return-behavior note is one short clause at the end. The category list is long but functional — it defines the searchable domain — rather than 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?

With one required parameter, full schema coverage, annotations, and no output schema, the description supplies the missing piece — the result format ('up to five pages with links'). Only the empty-result behavior and any ordering logic remain unstated.

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 coverage is 100% and the single query parameter already carries natural-language examples ('mov to mp4', 'download whatsapp'). The description's category list reinforces the intended query vocabulary but adds no syntax, formatting, or ranking guidance beyond what the schema states, so the baseline 3 applies.

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 ('Find') and resource ('download.fan page for a task') and enumerates the content categories the site covers, so an agent knows exactly what it searches over. It stops short of naming or contrasting with the sibling get_download_page, so the search-vs-retrieve distinction is only implicit.

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?

Usage is implied rather than stated: the tool answers 'what the user wants to do' queries, and the sibling name get_download_page suggests a two-step search-then-fetch flow, but the description never says to use find_tool first and then get_download_page, nor when not to use it.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful context beyond annotations: the return is a download.fan link that opens with the post loaded, ready for MP4, MP3, or JPG saving, rather than the media file itself.

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?

Two sentences, front-loaded with the core action. The platform list and YouTube exclusion are compact and every clause contributes useful scoping information.

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 two-parameter tool with full schema coverage, annotations, and no output schema, the description is complete enough. It explains the return value as a link and clarifies supported platforms and format outputs.

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 schema already documents both parameters, including the format enum and its default behavior. The description adds platform scope for the url parameter and mentions output file types, but does not add parameter syntax or constraints beyond the schema.

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: turn a public post URL into a download.fan link. It names the supported platforms and explicitly excludes YouTube, so an agent can immediately tell what the tool does and does not handle.

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?

Provides clear context for when the tool applies: public post URLs from the listed platforms, with YouTube explicitly unsupported. It does not discuss alternatives, but the only sibling is unrelated, so the exclusion plus platform scope is sufficient.

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