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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the bar for the description is lower. The description adds useful context by identifying USGS as the upstream source and confirming the query is time-bounded, but it says nothing about result caps, ordering, event-count limits, or what happens when only one of lat/lon is supplied.

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?

A single front-loaded sentence with no wasted words; the time window, source, and both optional filter families are stated compactly. It is efficient but undersized relative to a five-parameter tool, so the brevity costs more than it saves.

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 five parameters, zero schema descriptions, and no output schema, this one-sentence description leaves real gaps: default values, the co-dependency of lat/lon/radius_km, result limits, and the shape of returned events are all unstated. For a tool whose entire contract must be conveyed by prose, that is insufficient.

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 carries the parameter burden and does at least map every input to a concept: hours, min_mag, and the lat/lon/radius_km combination. However, it adds no units beyond the names, no defaults (hours defaults to 24, min_mag to null), no constraints (hours max 720, radius_km max 20000), and no rule that lat, lon, and radius_km must be used together.

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 names a specific resource (earthquakes), a specific source (USGS), and a specific time scope (last N hours), so an agent knows exactly what data comes back. It does not need to differentiate from siblings since no other sibling covers seismic data, but it also never states a verb or says whether this is a query-only read.

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 by the mention of optional magnitude and radius filters; there is no explicit 'use this when...' framing, no statement of when to omit lat/lon vs radius_km, and no alternatives named. An agent must infer that leaving the optional filters null returns all quakes in the window.

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