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

Even though annotations already mark this as read-only, idempotent, and non-destructive, the description adds substantial behavioral context: the response differs based on season_start, the cumulative mode includes observed history plus today plus forecast, and the tool supports calibrated crop thresholds. This goes well beyond what annotations convey and is particularly valuable with no output schema.

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 a single dense paragraph with no wasted words. It front-loads the tool's core function and geographic scope, then explains the two modes and ends with concrete example questions. Every sentence contributes useful decision-making 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?

With no output schema, the description compensates by describing both response shapes: per-day GDU across the forecast horizon versus cumulative season-to-date totals with a per-day cumulative series. It also covers default crop behavior, custom thresholds, optional milestones, and the USA-only geographic limitation. For an 11-parameter tool, this is complete enough to guide correct invocation.

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%, so the baseline is 3. The description adds meaning beyond the schema by explaining the crop='custom' plus base_temp_c flow, the behavior switch triggered by season_start, and the effect of upper_temp_c on method selection. Not every parameter is elaborated in the description, but the most semantically complex ones are clarified.

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 opens with a specific verb and resource: 'Growing Degree Units (GDU / GDD) for a US location (CONUS, Alaska, Hawaii), computed from daily max/min temperatures.' It also gives two concrete representative questions, 'how many growing degree days has my corn accumulated since May 1?' and 'what's the GDU forecast this week?', making the tool's purpose unmistakable and distinct from siblings like get_forecast or get_climate_normals.

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 clearly explains when to use each mode: without season_start you get per-day GDU, with season_start you get cumulative season-to-date totals, and it explains when to use a predefined crop id versus crop='custom'. It does not explicitly name sibling tools or when-not-to-use cases, but the mode-based guidance is strong enough that an agent can decide how to invoke it correctly.

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