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

Annotations only declare readOnlyHint=true and openWorldHint=false, so the description carries real added weight: it discloses a per-call price ($0.0045 USDC via x402), the exact unpaid-call failure mode, and the three ways to supply payment (X-PAYMENT header, PAYMENT-SIGNATURE header, or params._meta["x402/payment"]). It also states result ordering (newest first) and that the source is public-domain rather than a forecast. Minor tension worth noting: it queries a live external USGS service while openWorldHint is false, but this is an annotation-level ambiguity rather than a description contradiction.

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 tight sentences lead with what the tool returns, then the search shape, then cost and the payment retry path — the most failure-prone detail is placed last but clearly delimited. The payment sentence is dense with headers and a JSON path, but every clause is actionable rather than filler.

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 compensates by enumerating the returned fields (magnitude, depth, felt reports, time) and the sort order, and it fully covers the paid-call failure mode an agent will actually hit. For a read-only lookup of moderate complexity, that is close to complete; only the relationship between the date window and radius filtering is left to the schema.

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%, so the schema already documents defaults, ranges, and formats for all seven parameters, which sets the baseline at 3. The description adds only the ordering guarantee ("newest first") and the out-of-schema payment channel params._meta["x402/payment"]; it does not clarify how since/until interact with radius_km or min_magnitude, so it stays at baseline.

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 opening sentence names the resource (USGS earthquakes), the spatial scope (near a point), and the payload fields returned (magnitude, depth, felt reports, time), while "bounded date/radius search, newest first" supplies the operation. It is clearly distinguishable from place_weather_alerts and place_disasters by source and content, though it never uses an explicit verb like "search" or "list" and does not name those siblings.

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?

Usage is only implied: the point-plus-date/radius framing and the "not a safety forecast" caveat suggest when it fits, and the payment paragraph explains how to retry after a 402. There is no explicit statement of when to prefer this over place_disasters or other place_* tools, and no exclusions or prerequisites beyond payment.

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