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

Annotations already indicate this is a non-read-only, non-idempotent, non-destructive operation. The description adds valuable behavior beyond annotations: automatic geocoding of plain addresses, lat/lng override behavior, and quota impact ('Counts against the plan's location allowance'). It does not describe return values, but the safety profile is already carried by 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?

Three short sentences, each earning its place: purpose, geocoding behavior, and quota consequence. It front-loads the core action and avoids repeating detailed schema 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?

For a 22-parameter create tool with no output schema and minimal annotations, the description covers the essential non-obvious context: what the operation does, geocoding behavior, and plan allowance impact. It does not address return values or duplicate handling, but the schema is rich enough that these are minor gaps.

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 description adds a cross-parameter decision rule: a plain address is geocoded automatically and lat/lng are only needed to override that result. With schema description coverage at 64%, this helps compensate for undocumented parameters, though many fields still rely on their schema descriptions for full meaning.

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 states a specific verb ('Add') and resource ('a location to the locator'), which clearly distinguishes it from sibling tools like update_location, delete_location, get_location, and list_locations. The title reinforces the action without ambiguity.

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 implies when to use the tool through 'Add a location' and gives conditional parameter guidance about geocoding, but it does not explicitly name alternatives or state when to prefer create_location over update_location. The allowance warning is useful context but not tool-selection guidance.

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