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

Annotations only cover readOnlyHint and openWorldHint (both consistent with a static archived snapshot read), so the description's additions are genuinely load-bearing: snapshot staleness, unknown current conditions, cost of $0.01 USDC, the shared free allowance, and the exact x402 retry protocol including '_meta["x402/payment"]' and the prohibition on separate USDC transfers or silent fallback. That is unusually rich behavioral disclosure an agent cannot get from structured fields.

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?

Purpose is front-loaded, but the text is bloated with near-duplicate hedging ('Illustrative output excerpt' repeated, 'not a live result, signature, approval or guarantee' stacked with 'Freshness/data/availability checks still apply') and a payment walkthrough longer than the tool description itself. Many sentences do not add distinct 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?

With no output schema, the description does supply an illustrative response shape and the key caveat that distances are 'great_circle_not_road_distance', and it covers cost and payment mechanics thoroughly. What's missing is coverage area of the snapshot and parameter meanings, but an agent could call it correctly from this text.

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 0%, so the description must compensate. It provides a concrete example object covering all five parameters and the phrase 'straight-line proximity' implicitly explains radius_km, but it never defines what 'service' enum values mean, what 'limit' bounds, or how radius and limit interact. Partial compensation only.

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 first sentence states a specific verb and resource (nearest RV dump/water stations) and names the exact data source (FillPoint's dated September 17, 2026 ODbL snapshot), with the computation method spelled out as bounded straight-line proximity. It doesn't need sibling differentiation because no sibling in the list is a proximity/station lookup, but the signal is diluted by payment boilerplate that follows.

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 lists what the tool is NOT for: 'not live access, potable-water assurance or road routing', plus 'Freshness/data/availability checks still apply', which effectively tells an agent when to reach for other tools. It also clearly defines the free-trial path (3 eligible calls per IP per UTC day) versus paid continuation and instructs STOP-and-approve before paying. No named alternatives are given, which keeps it below a 5.

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