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

Since no annotations are provided, the description carries full responsibility for disclosing behavior. It does so effectively: it states the tool 'Read[s] from the USA-NPN degree-day forecasts' rather than a local list, explaining external dependency. It discloses that some layers carry accumulated heat and are 'counted and named as unreadable rather than rendered as dates,' and that insect observations come from iNaturalist with possible search widening to surrounding country. These are meaningful behavioral caveats that affect interpretation. It implicitly signals a read-only operation, though it does not explicitly mention authentication or side effects, which are covered by schema parameters.

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 verbose, spanning three paragraphs. It front-loads the purpose in the first sentence, then explains data provenance and quirks. While every paragraph adds useful context about data reliability, the text is longer than necessary and could be tightened. It is not excessively padded, but it is not concise either. It earns a 3 for being structured and informative without being wasteful.

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 query tool with an output schema (the signal indicates one exists), the description does not need to explain return values. It explains the data sources, the interpretation caveats (unreadable heat sums, iNaturalist observation widening), and the block parameter is thoroughly described in the schema. It does not mention billing or npub, but those are captured in the schema's npub description. Overall, the tool is adequately specified for an agent to understand what it does, how data behaves, and how to invoke it correctly.

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?

The tool description does not discuss any parameters; it relies entirely on the input schema. Schema coverage is 67% (two of three parameters have descriptions). The block parameter description is detailed, explaining how to reference saved blocks and the behavior on multiple matches. The description adds no further meaning to parameters, so it does not compensate for the missing dpop_token description. Given coverage is above 50% but below 80%, the baseline of 3 is appropriate.

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 first sentence clearly states the tool's purpose: 'Which pest stages are modelled for this ground this season.' This is a specific verb (answer/retrieve) with a resource (pest stages for a block). It distinguishes itself from siblings like pest_threshold (likely thresholds) and wildlife_catalog by focusing on pest stages per season, but it does not explicitly name alternatives. The description adds context about data provenance but the core purpose is clear.

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 does not provide explicit when-to-use or when-not-to-use guidance. It explains how data is sourced and interprets some quirks, but never directs the agent to prefer this tool over siblings like pest_threshold or crop_gdd_status. No alternatives are mentioned, nor are conditions for exclusion. The agent must infer usage from the schema and context.

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