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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description adds real behavior: the source is inferred from the id format, return fields vary by source, IRSC ids resolve only against the latest ~20 events, and times are returned in both UTC and Tehran. It stops short of describing not-found behavior or error cases.

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 and scope are front-loaded in the first clause, before the source-specific detail. The parenthetical field enumerations are information-dense and mostly earn their place, though the per-source listing is long enough to make it slightly heavy for a one-parameter tool.

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 effectively enumerates the returned fields per source and states timezone conventions, and annotations cover the read-only/idempotent profile. For a single-parameter lookup, an agent has everything needed to call it and interpret the result.

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 documents the id pattern and example formats, so the baseline is 3. The description goes further by explaining that the id format itself determines which source (and therefore which fields) you get, which is functional parameter semantics not present in the schema.

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?

A specific verb ('Get') plus resource ('one earthquake in full') with an explicit scope that sets it apart from the list-oriented siblings eq_search/eq_latest/eq_significant/eq_stats. It never names a sibling directly, so differentiation is by scope inference rather than explicit contrast.

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 implied: you need a single event's full record and an event_id drawn from another eq_ tool (stated in the schema/description). There is no explicit when-to-use/when-not or a named alternative for the single-event case, leaving the routing to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds behavior the annotations cannot: results are ordered newest-first, and returned timestamps appear in both UTC and Tehran time (UTC+03:30). It does not discuss rate limits or freshness/latency of the upstream feeds.

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?

Two tight sentences, front-loaded with purpose and scenario, followed by field conventions and sibling routing in one line. No filler and nothing repeated from the schema or annotations.

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 optional params all fully documented in the schema and no output schema, the description usefully compensates by naming the returned fields (time_utc, time_tehran, depth_km, mag_type) and the result ordering. An agent has everything needed to call it and interpret the response.

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%, including enum, ranges and defaults (limit capped at 50 to stay under 15 KB, source ids not interchangeable), so the schema carries the input burden. The description's extra detail (time_utc/time_tehran, depth_km, mag_type) describes output fields rather than adding meaning to the five input parameters, so the baseline 3 applies.

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?

States a specific verb and resource with scope and ordering: "List the most recent earthquakes in Iran, newest first." That clearly separates it from eq_detail (single event) and eq_stats (counts), which the description also names. It never distinguishes itself from eq_search or eq_significant, so it falls short of full sibling differentiation.

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?

Gives a concrete triggering scenario ("was there an earthquake today?") and routes to alternatives by function: eq_detail for more on an id, eq_stats for counts. There is no explicit when-not guidance (e.g., non-Iran queries or historical ranges belong elsewhere), so it is clear context without exclusions.

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

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

Annotations already mark this safe/idempotent/open-world, so the description correctly spends its budget on non-obvious behavior: USGS/EMSC lack a province field, IRSC keeps only ~20 events, `more` semantics including the newest-500-event scan cap, UTC vs Tehran time fields, and depth units. This is exactly the extra context that annotations cannot convey.

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?

Front-loaded with purpose and use cases, then grouped caveats. Dense and mostly earned, though the second paragraph stacks several distinct warnings (source limits, time fields, `more` semantics) that could be tightened into a cleaner list.

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 10 parameters, no output schema and rich source-dependent behavior, the description covers the gaps an agent needs: partial-result signalling via `more`, which returned fields exist, and how source choice changes filtering. Nothing essential to calling it correctly is missing.

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 baseline is 3. The description mostly restates what the schema already documents (place matching, bbox default of all Iran, source enum meanings); the genuinely additive lines (cross-source field differences, IRSC's recency window) are behavioral rather than parameter semantics.

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?

States a specific verb (Search), resource (earthquakes), scope (in Iran) and the four filter dimensions (date range, magnitude, bbox, place). The sibling set (eq_latest, eq_significant, eq_detail, eq_stats) is implicitly differentiated: this is the historical/filtered query tool, not latest/significant/detail/stats.

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?

Gives explicit use cases ('Use for history: "M5+ in 2026", "quakes near Bam"') and practical caveats (source='irsc' only has ~20 latest events; narrow dates or bbox when more=true). It does not, however, name the sibling tools it should be preferred over (eq_latest, eq_significant), so the routing guidance is one-sided.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so safety is covered. The description adds useful non-schema context about the returned data: times given in both UTC and Tehran (UTC+03:30) and depth_km units, which matters since there is no output schema.

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?

Two short sentences, zero waste, with the core purpose and ordering front-loaded before the usage cue and unit notes.

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 usefully discloses the time and depth unit conventions for returned fields, and the schema covers all inputs. It could go further on what fields each event carries, but for this tool it is largely 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 description coverage is 100%, so all five parameters (days, limit, source, iran_only, min_magnitude) are already fully documented with defaults and enums. The description adds no parameter-level meaning beyond noting the output units, so baseline 3 is appropriate.

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?

States a specific verb (List), resource (earthquakes), geographic scope (Iran), and ordering (largest magnitude first). This distinguishes it in spirit from eq_search/eq_latest, though it never names those siblings explicitly.

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 phrase 'Use for "biggest earthquakes this month/year"' gives a concrete usage cue, but it offers no exclusions or routing against the four sibling tools (eq_search, eq_latest, eq_detail, eq_stats), leaving the agent to infer which one to pick.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the description is free to spend its words on data behavior. It does: places are nearest-town/EMSC-region labels with no province data, and `truncated` reveals that counts can silently reflect only the newest events because the source capped at 3000 rows before Iran filtering. That truncation disclosure is exactly the kind of trait annotations cannot convey.

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 scope and output shape come first, then the usage trigger, then two dense caveats. Three sentences, no filler, and every clause carries information an agent cannot get from the schema or annotations.

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 and no annotations on return shape, the description carries the burden and largely meets it: it names the three result components and the truncation flag, and notes source-specific limitations (IRSC only ~20 events). It stops short of describing the exact structure or empty-result behavior, but an agent has enough to call and interpret it.

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%, so the baseline is 3, but the description adds cross-parameter meaning the schema lacks: place values depend on which source is chosen, and `truncated` interacts with the iran_only/source filtering. It clarifies semantics rather than restating the schema.

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?

States a specific verb (Count) and resource (earthquakes in Iran) plus the exact aggregations returned: magnitude band, place, and strongest event. The counting/aggregation framing is implicitly distinct from siblings like eq_search or eq_detail, but no sibling is named explicitly, so it falls just short of a 5.

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?

Gives a concrete usage trigger ("how active has Iran been this month"), which maps cleanly onto an activity-summary tool rather than an event-lookup tool. It gives no explicit exclusions or named alternatives (e.g. eq_search for individual events), so it is clear context without routing guidance.

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