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

Annotations already cover readOnly, idempotent, non-destructive and closed-world, but the description adds concrete operational context: no network, no stored state, determinism, and hard limits (64 KB input, 1 s per call, 1 MB output). Those limits are genuinely useful for call planning and are not visible in the 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?

Well front-loaded with labeled sections, but the entire content is duplicated verbatim in Spanish and English, roughly doubling length for a two-parameter formatter. The 'When' sentence does not earn its place because it describes tasks the tool does not do.

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?

An output schema exists, so return-value explanation is unnecessary; limits, determinism, side effects and the inverse-tool alternative are all covered. The only shortfall is that the description never mentions the seconds_decimals output-formatting choice, which is the one behavioral knob an agent might want set deliberately.

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 description coverage is 100%, with lat/lon ranges, examples and the seconds_decimals default already documented in the schema. The description adds no per-parameter meaning (it does not explain the 0-4 seconds_decimals range or the two output formats' relationship to it), so the baseline 3 applies.

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?

States a specific verb and resource: formats decimal latitude/longitude into DMS and degrees-decimal-minutes, including hemisphere letters. It explicitly names the sibling it is not (coordinates-to-decimal), so an agent can distinguish the two without opening either schema.

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 'Not for' clause explicitly routes the inverse operation to coordinates-to-decimal, which is exactly the disambiguation an agent needs. However, the 'When' clause ('coordinates, distances, bearings or areas have to be computed from given points') describes computation tasks this formatting tool does not perform, making the positive trigger vague and slightly off-target.

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