Geocode a place name

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

With no annotations to fall back on, the description carries the full burden of behavioral disclosure. It captures the core operation but omits at least one behavior implied by the schema: the ability to return multiple matches for an ambiguous name like 'Bergen.' It also doesn't disclose ordering ('Bergen, Norway' disambiguates, but the description doesn't mention it), potential for empty results, or rate limits. The description is true but under-specified.

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?

Two tight sentences, zero filler. The first sentence carries the functional weight; the second is a short bridge to the workflow it serves. Nothing to cut, and no fluff to trim.

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 tool this simple—2 params, no nested object—the description covers the core contract adequately. The missing piece is the multi-match behavior: an agent calling this with a generic 'Bergen' might not realize it can receive several candidate coordinates and would benefit from a hint about result order or how to disambiguate (e.g., 'the first result is the most likely match').

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 for the 2 params is 100%: both 'name' and 'count' are documented inline with types, defaults, and examples, so the description doesn't need to re-explain them. It does miss a chance to clarify that 'count' controls the multi-match limit, but per the rubric, baseline 3 applies when schema coverage is high. No deduction needed.

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?

Clear verb+resource: "Find latitude and longitude for a place name" precisely states what the tool does. While the verb 'Find' is generic, the resource is specific enough that an agent won't confuse it with the sibling tools, which all handle weather data.

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 second sentence, 'Use the coordinates with the other tools,' offers only a weak procedural hint and not actual decision guidance. No mention of when to choose this over siblings, no exclusions, no edge cases like ambiguous place names. The sibling tools are all so clearly weather-specific that an agent can infer the geocoding role of this tool, but the description itself doesn't lay it out.

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