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

With no annotations at all, the description carries the full burden, and it does disclose important behaviors beyond the schema: years without cause data reflect absence from the hotspot ranking, not zero accidents; the last year is a preliminary estimate, so the count trend alone must not be read as improvement; and the default year set is the upstream's most recent 3 published years. It does not state access permissions, rate limits, or response shape, but it gives more substantive behavioral context than most.

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?

It is a single dense sentence built from semicolon-separated clauses, front-loading the core purpose (trend query) before the caveats. Some content duplicates the schema (max 5 years, default 3 years, identifier provenance), and splitting it into shorter sentences would improve readability, but nothing is truly wasted.

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 6-parameter analytical tool with no output schema, the description covers what is returned (yearly counts, causes, collision types), how missing-cause years should be interpreted, and the preliminary nature of the latest year. An agent has everything needed to call it and to interpret the result 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?

Schema coverage is 100%, so the baseline is 3. The description still adds real meaning: it identifies get_cbi_hotspots as the source of kind and locationKeyid, explains that area narrows the ranking scan, and warns that switching metric may be necessary to find an intersection in a given year. That is provenance and intent beyond what the schema documents.

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 names a specific verb and resource: querying the year-by-year accident-count trend (since 民國 106) for a single intersection or road segment, plus the causes and collision types for specified years. It also makes clear the data grain (single location, multi-year) and the provenance of the identifiers, so an agent can distinguish it from sibling tools such as get_location_history or get_location_overview.

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?

It explicitly says that kind and locationKeyid must come from get_cbi_hotspots, that city/area/metric are used to scan each year's ranking, and that metric matters because an intersection may only appear in another metric's ranking in some years. It also gives the default year behavior. The gaps are the absence of explicit exclusions such as 'use get_location_history instead when…', but the context for correct use is otherwise clear.

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