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

Annotations already signal readOnly/idempotent/non-destructive, so the description adds meaningful behavior beyond that: the 2-hour threshold, current conditions for un-timed or near legs, and daily forecast for future legs. This is useful dynamic context without contradicting annotations.

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?

Four short sentences, all substantive; every sentence earns its place and the main purpose is front-loaded. No redundant restatement of the schema.

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 route-based forecast tool with rich annotations and a schema that already documents the legs array and units enum, the description covers the key behavioral twist (2-hour current/future forecast) and use cases. It does not detail the output shape, but no output schema exists and the annotation set already covers safety and side-effect expectations.

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?

With only 50% schema description coverage, the description compensates by explaining that legs are lat/lon waypoints, that departs_at is optional ISO 8601, and exactly how departure time changes results (current vs daily forecast). It leaves the units enum to the schema, which is acceptable since that parameter has an enum and default.

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 opening phrase 'Weather conditions along a polyline route' names a specific resource and behavior, and the description then details the leg-based input. It clearly distinguishes this from sibling weather tools like weather_zip, weather_current, and weather_forecast by focusing on multi-point routes.

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 gives clear context for when the tool is relevant: 'For trucking, road-trip, and delivery-window planning,' and explains the current-vs-forecast split based on departure time. It does not explicitly name an alternative or state when not to use it, so it stops short of full routing guidance.

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