List local AmeriFlux and FLUXNET files

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds real behavior: each archive's members are classified by kind, site, resolution, years and version, and unsafe members are flagged. The phrase 'stdio only' is unexplained and is the one piece of context an agent cannot act on.

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 purpose, then scope, then classification behavior, then the next action. The middle sentence is a dense enumeration of file kinds and member fields that borders on over-packed, but no sentence is 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 an output schema present the description needn't explain return values, and annotations cover mutability, so the remaining burden is scope and post-call routing — both supplied. The gaps are pagination behavior for limit/offset and the opaque 'stdio only' clause.

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 67%, and the description covers the spirit of path (download directory / configured local roots), site, and include_members ('members classified by kind'). It says nothing about limit/offset paging despite those being 2 of the 6 parameters, so the schema still carries the paging semantics.

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 ('Find the AmeriFlux and FLUXNET files already on this computer') and enumerates the artifact families it covers (BASE/BASE-BADM zips, BIF, ONEFlux, FLUXNET2015). The 'already on this computer' scoping immediately distinguishes it from siblings like amf_search_sites and amf_get_availability, which operate on remote catalogs.

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 a clear next-step handoff ('call amf_preview_data(file=...) on one'), which is genuinely useful routing. However, it never states when NOT to use it — e.g., that a site not present locally should be fetched first or looked up via amf_search_sites — so the alternative path is left implicit.

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