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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the description correctly aligns with those. It adds valuable context about behavior: products are omitted when none exist, and small automatic events may have no detail while large reviewed ones have most. It also states this is USGS-only, which is a behavioral constraint. No contradictions with annotations. The description goes beyond structured fields by explaining output variability based on event type.

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?

The description is dense but every sentence contributes. It leads with the purpose, then lists the projection of products, notes the omission behavior, mentions the source of event IDs, and ends with the USGS-only limitation. No redundancy or filler. While it's longer than minimal, the complexity of listing many products warrants the length. It's well-structured and front-loaded.

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?

The tool has one parameter, an output schema exists, and the description covers the purpose, the source of the event ID, what to expect in terms of product presence, and the USGS-only constraint. It also differentiates from siblings. For a single-event detail tool, everything an agent needs to decide when and how to call it is present. The absence of pagination or authorization details is irrelevant given read-only and open-world hints. The description is complete.

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 100% and the schema already describes event_id with examples and where to find it. The description adds a little extra by confirming that event IDs come from the 'id' field of feed/search results, which reinforces the schema. While the schema is fully descriptive, the description provides the same information in prose, which slightly enhances clarity but is not strictly necessary. Given high schema coverage, a baseline of 3 is appropriate, but the description adds just enough context to justify a 4.

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 clearly states the tool's purpose: fetch detail for a specific earthquake by USGS event ID. It distinguishes itself from feed/search by explaining it returns the same normalized event plus analysis products only available in a single-event response. It also explicitly limits to USGS events, which differentiates it from 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?

The description clearly implies when to use: when you already have an event ID from feed/search results, and it explicitly says this is USGS-only, so not for EMSC events. It doesn't explicitly say 'use this instead of search when you have an ID', but the context of 'Event IDs appear in the 'id' field of earthquake_get_feed and earthquake_search results' and 'returns the same normalized event a search result carries' makes the use case clear. It could be more explicit about alternatives, but it's sufficient.

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