fdsn_get_allorigins_by_id

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

Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, read-only, idempotent operation. The description adds context beyond annotations by explaining that multiple origin solutions are returned and listing available datacenters. It also highlights the opaque nature of eventid, adding meaningful behavioral context. Not quite a 5 because it doesn't describe pagination or result format, but annotations cover the safety profile adequately.

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 compact and front-loaded. It starts with the core purpose, then gives usage context, then the eventid constraint, and ends with datacenter options. Every sentence earns its place; there is no fluff or repetition. Length is appropriate for the complexity.

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 an output schema (though not shown), so return format is presumably documented there. The description covers purpose, usage, critical input constraints, and available datacenter choices. Given the annotations and schema, it is complete enough for an agent to select and invoke the tool correctly. No major gaps.

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%, but the description fully compensates. For eventid, it explains that it is an opaque provider-specific string, must be copied verbatim from a previous query, and should never be invented or guessed. For datacenter, it lists concrete valid values (INGV default, EMSC, GFZ, USGS) and notes ObsPy support. This adds rich meaning beyond the bare schema types.

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 gets 'all computed origin solutions (hypocenter locations) for an earthquake event.' This is a specific verb+resource combination that distinguishes it from siblings like fdsn_get_earthquake_by_id, which likely retrieves a single event record. It directly addresses the domain of alternative locations and agency-computed origins.

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?

Explicit usage guidance is provided: 'Use this when asked about alternative locations, origin comparisons, or which agencies computed origins.' It also gives a critical operational constraint: eventid must be copied verbatim from a prior fdsn_query_earthquakes result and never guessed or reformatted. This is clear when-to-use and prerequisite handling.

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