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

Goes well past the annotations: it discloses that the conversion is offline and deterministic, that input format is auto-detected (including messy free-form DMS), and that each successful call costs $0.001 USDC via x402 on Solana, plus an equivalent HTTPS endpoint. Cost per call and network/payment behavior are exactly the kind of facts an agent cannot infer from readOnlyHint/idempotentHint.

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?

Front-loads the capability and format list, then tacks on operational facts (offline, price, HTTPS URL) — all of which earn their place. The dense parenthetical format qualifiers make the first sentence long but remain scannable.

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?

There is no output schema, and the description never says what comes back — whether all formats are returned or only a target one (there is no `to` parameter, so this is genuinely ambiguous). Precision parameters are also unexplained. For a 4-parameter conversion tool with no output contract, more should be spelled out.

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 75%, so most parameters are already documented. The description only adds meaning for the auto-detect path and geohash "with cell size"; mgrsDigits (precision digits per axis) and geohashPrecision are left entirely to the schema, and the interaction between an explicit `from` value and auto-detection is not clarified.

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?

Names a precise verb (convert) and resource (a location between coordinate formats) and then enumerates every supported format — decimal degrees, DMS, UTM, MGRS, geohash, Maidenhead, plus codes — with domain qualifiers (Krüger series, WGS-84, Norway/Svalbard zones). This clearly separates it from geocode, geo_distance and geo_polygon, which do lookup/measurement rather than format transcoding.

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 it ("in one call", auto-detection, free-form DMS input) but never explicitly contrasts it with the neighboring geocode or geo_distance tools, nor states when-not to use it. The pricing and HTTPS-endpoint notes give useful calling context but are not usage guidance.

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