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

Annotations already mark readOnlyHint=true and openWorldHint=true. The description adds substantial behavioral context beyond these hints: it explains that data comes from multi-state feeds, is normalized, includes various event types (incidents, roadwork, closures, chain advisories, wildfires), that coverage varies by state, that states are added automatically, and that every event includes a source field. This goes far beyond what annotations alone convey, giving the agent a realistic picture of data variability and output expectations.

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 appropriately sized given the tool's complexity. It is front-loaded with the primary purpose in the first sentence, then logically proceeds through data scope, coverage caveats, usage guidance, and parameter explanations. Each sentence provides necessary information and none is redundant or filler. It is well-structured with clear paragraph breaks for readability.

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 and only read-only/open-world annotations, the description carries the responsibility of explaining what the agent will receive. It clarifies that events are normalized across state feeds, includes a source field with the publishing agency, and covers the event types and filtering options. It also addresses edge cases like state coverage variability and toll prices. This provides a complete context for using the tool effectively, even without an output schema.

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 input schema provides only types, titles, defaults, and no descriptions (coverage 0%). The description fully compensates by defining the center format ('"lat,lon"'), explaining the kinds parameter as a comma-separated list with an explicit enumeration ('incident, closure, chain, fire, sign, rwis, camera, toll'), and noting the radius_km cap ('caps at 160'). This is essential semantic detail that the schema lacks.

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 clearly states the tool's purpose: 'Live road events near a point anywhere CommuteScout covers, not just California.' It uses a specific verb ('get' implied by name) and resource ('live road events'), and distinguishes itself from the California-specific siblings by explicitly directing users to prefer dedicated tools for California and to use this one for outside California or border areas.

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 explicit when-to-use guidance: 'For CALIFORNIA questions prefer the dedicated tools above... Use THIS tool for any location outside California, near a state border, or as a supplement when a California tool comes back empty.' This names the alternatives and gives clear conditions, which is exactly what this dimension requires.

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