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

Even with strong annotations (readOnlyHint, idempotentHint), the description adds significant behavioral detail: multiple features per dam are all returned, HazardCl measures consequence rather than likelihood, federal dams are omitted, and the output is not an evacuation map. This goes well beyond what annotations or the schema 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 description is compact and front-loaded. The first sentence states the core purpose; subsequent sentences each add meaningful caveats about multiple features, HazardCl interpretation, federal exclusions, and non-evacuation use. No sentence is wasted.

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?

Given the output schema and annotations, the description covers all essential behavioral context: what the tool reports, how to interpret HazardCl, what is excluded, and what the results are not. The location input is fully documented in the schema, so nothing critical is missing for an agent to invoke it correctly.

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%, and the Location schema already explains address vs. coordinates and the geocoding shortcut. The tool description only says 'at a location' and does not add parameter-level meaning beyond what the schema provides, so the baseline score of 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?

The description clearly identifies the resource as DWR dam inundation areas and explains the concept: 'where water could flood if a dam failed.' It distinguishes itself from more general flood/hazard tools by focusing on dam failure, but it is phrased as a noun phrase rather than an explicit verb-driven action such as 'returns' or 'lists,' so it stops just short of top marks.

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 gives useful context: it covers dam-failure inundation, excludes federally owned dams, and warns 'Not an evacuation map.' However, it never explicitly states when to use this tool versus siblings like flood_zone or hazards_at_location, nor does it name alternatives or give clear when-not-to-use conditions beyond the evacuation caveat.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the tool's coverage limitation (only recently burned areas), the typical not_in_zone result for unburned areas, and the important caveat that not_in_zone does not imply no risk. This goes beyond the annotations by explaining the tool's real-world behavior and interpretation of results.

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 two sentences with zero waste. The first sentence states the purpose and scope; the second delivers the critical caveat about not_in_zone. Every word earns its place, and the most important behavioral caveat is front-loaded in the second sentence.

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 a single parameter fully documented in the schema, an output schema exists, and annotations cover the safety profile. The description adds the only missing context: coverage limitations and interpretation of the not_in_zone result. An agent has everything needed to call this tool correctly and interpret its 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 description coverage is 100%, so the schema already documents the location parameter thoroughly, including the address/lat-lon alternatives and the note that coordinates skip geocoding. The description doesn't add parameter-level detail beyond what the schema provides, but it doesn't need to. Baseline 3 is appropriate since the schema carries the full burden.

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: USGS post-fire debris-flow assessments at a location. It specifies the resource (USGS post-fire debris-flow assessments), the action (returns assessments at a location), and distinguishes it from generic hazard tools by noting the USGS only assesses recently burned areas. This is a specific verb+resource combination that differentiates it from siblings like flood_zone or seismic_zones.

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 explicitly tells the agent when to use this tool and what to expect: it only covers recently burned areas, and it gives a concrete example (Glendale) where it will usually return not_in_zone. It also warns that a not_in_zone result does not mean no debris-flow risk, which is critical for correct interpretation. This is explicit usage guidance beyond what the schema provides.

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?

Beyond the read-only and idempotent annotations, the description discloses valuable behavioral details: inferred meanings are explicitly flagged, freshness includes fetched_at and source_last_edit, and the output includes the covered area, source URL, and disclaimer. This helps the agent trust and interpret the data correctly.

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 dense sentences with no filler: the first front-loads the primary purpose and output contents, the second gives actionable usage guidance. Every clause earns its place.

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?

For a simple single-parameter tool with a rich output schema and safety annotations, the description provides everything needed: what the tool returns, how to interpret its outputs, and when to call it relative to sibling tools. No important context 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 input schema already fully documents the single parameter. The tool description itself does not add much parameter-level detail beyond 'Describe one dataset,' but no compensation is needed because the schema already provides the meaning.

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 opens with a specific verb and resource, 'Describe one dataset,' and enumerates exactly what the output contains: fields, types, meanings, coded values, record count, freshness, coverage, source URL, and disclaimer. It clearly distinguishes itself from list_datasets by focusing on a single dataset and from query_dataset by positioning itself as the interpretive precursor.

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 explicitly tells the agent when to use this tool: 'Read this before filtering with query_dataset, and to interpret attributes returned by other tools.' It even gives concrete examples such as FEMA FLD_ZONE codes and CAL FIRE FHSZ codes, making the routing decision unambiguous.

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, and non-destructive, but the description adds important interpretation beyond those: every FEMA zone counts as in_zone including X, SFHA_TF should be read, and Zone D means not studied and not safe. This prevents misleading conclusions and adds genuine behavioral context.

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 dense, purposeful sentences with no filler. The core resource and behavior are front-loaded, and the caveats about zone classes are packed efficiently into the remaining sentences.

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?

For a single-parameter tool with an output schema and robust annotations, the description is complete. It covers the core query, the result semantics, and the critical safety interpretation, leaving no major gap for an agent to call and use it correctly.

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%, with the Location object fully explaining address vs. lat/lon usage and noting that coordinates skip geocoding. The tool description itself adds no additional parameter detail, so the baseline of 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?

The description identifies a specific resource (FEMA National Flood Hazard Layer), a clear operation (look up flood zone at a location), and the key output concept (nearest zone of each FLD_ZONE class). It distinguishes itself from hazard siblings by name and content, making the tool's purpose unambiguous.

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 establishes when this tool applies: for FEMA flood zone information at a location, including how to interpret zones. It does not explicitly name alternatives or exclusions, but the context is strong enough that an agent can route flood-specific requests here without confusion.

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 as read-only, but the description adds valuable behavioral detail: it returns a matched address, coordinates and score, may return multiple candidates for ambiguous addresses, errors on outside-city addresses, and ignores unit numbers. Nothing in the description contradicts the annotations.

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, with every sentence contributing useful information: what it does, what it returns, error behavior, input limitations, and when to use it. There is no filler or redundancy.

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?

For a single-parameter, read-only tool with an output schema and rich annotations, this description is fully adequate. It covers invocation, return shape, edge cases, and explicit usage guidance without needing to restate structured data.

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?

The schema already documents the single 'address' parameter fully, so the baseline is 3. The description adds useful interpretive meaning beyond the schema by explaining ambiguity handling, unsupported place names, and ignored unit numbers, making the tool's input behavior much clearer.

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 uses a specific verb and resource: it finds a Glendale street address via a city geocoder, and tells the agent exactly what the tool returns. It also differentiates itself from other tools that accept an address directly, so an agent can identify this tool's unique role.

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 explicitly states when to call this tool: 'call this only to check or disambiguate one' and notes that other address-accepting tools make this unnecessary in normal flows. It also gives boundary conditions such as outside-city-limit errors and unsupported inputs like place names or unit numbers.

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?

Even though annotations already mark this as read-only, idempotent, and non-destructive, the description adds meaningful behavioral context: these are regulatory maps, not current conditions or safety assessments, and each hazard result includes status, containing zones, nearest zone distance, and reading notes. This goes well beyond what annotations alone provide.

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, front-loads the core value proposition, and every sentence earns its place: the hazard list, the output contents, the important regulatory caveat, and the routing to alternatives. No fluff or redundancy exists.

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?

For a multi-hazard lookup tool with a rich output schema and annotations covering safety and idempotency, the description is complete. It covers what the tool returns, distinguishes itself from real-time safety products, and directs the agent to alternatives, leaving no critical decision unresolved.

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%, and the schema already thoroughly documents the location parameter, including examples and the note that coordinates skip geocoding. The tool description does not need to add much about parameters; it contributes little beyond the schema, 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?

The description states a specific purpose: retrieving all mapped hazards at a single location in one call, then enumerates exactly which hazard types and agencies are included. It clearly contrasts with sibling single-hazard tools by presenting itself as the consolidated option.

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 gives explicit when-to-use guidance: use this for consolidated hazard-zone data, use single-hazard tools when only one hazard is needed, and use read_guide('real_time_sources') for active fires, evacuations, and alerts. This is strong routing behavior.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating operation. The description adds the 'offline snapshot or live' distinction as part of the output, but does not discuss performance, pagination, or any other behavioral nuance. Given the strong annotation coverage, a 3 is appropriate – the description adds modest context without contradicting the annotations.

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 two sentences, front-loaded with the core function and output fields, followed by usage guidance and alternatives. Every sentence earns its place; there is no fluff or redundancy. It is an exemplary model of conciseness.

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?

For a zero-parameter list tool with an output schema (as signaled by has_output_schema=true), the description fully covers what the tool does, what it returns, how to use it, and when to use alternatives. Nothing an agent needs to call 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?

The tool has zero parameters, and the schema coverage is 100% (empty schema). Per the rubric, a tool with no parameters gets a baseline of 4. The description does not need to explain parameters because there are none, and it does not introduce any misleading parameter references.

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 opens with a specific verb and resource: 'List every dataset this server can query' and enumerates the returned fields (id, source agency, category, snapshot/live, feature count). It clearly distinguishes itself from sibling tools like describe_dataset, query_dataset, hazards_at_location, and nearest_resources by stating its role as the entry point for dataset discovery.

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 explicitly states when to use this tool ('Start here to find dataset ids for describe_dataset and query_dataset') and when not to ('For hazards or resources at a location, the dedicated tools (hazards_at_location, nearest_resources) are simpler'). It names the alternatives and the conditions that select them, leaving no ambiguity.

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 readOnlyHint=true and idempotentHint=true. The description adds critical behavioral details: distances are straight-line meters (not travel distance/time) and only resources inside Glendale are included, even if neighboring cities are closer. This goes beyond annotations and is essential for correct interpretation.

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 sentences, front-loaded with the primary purpose, followed by essential caveats and a routing instruction. No wasted words; every sentence earns its place.

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?

Given the tool's complexity (multiple resource kinds, location input, limit, and output fields), the description covers the key nuances: Glendale-only scope, straight-line distances, and a clear pointer to an alternative for different filters. The agent has all necessary context to invoke the tool correctly.

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 parameters are well-documented in the schema (e.g., location accepts address or lat/lon, kinds has enum, limit has default and range). The description does not add new parameter semantics beyond what the schema already provides. Baseline of 3 applies because the schema carries the burden.

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 states a clear verb ('Nearest') and resource ('community resources') with an explicit list of types and output fields. It also distinguishes itself from query_dataset by name, making it easy for an agent to select the right tool.

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?

It explicitly instructs when to use an alternative: 'For other filters (e.g. only high schools) use query_dataset.' It also clarifies the scope (only Glendale) and the distance metric, setting clear expectations for usage.

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 readOnlyHint, idempotentHint, and non-destructive nature. The description adds valuable behavioral details: geometry is off by default to save context, results include total and next_offset for paging, and data source differences (live vs snapshot). This goes beyond the structured annotations and helps the agent set expectations.

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 concise (three sentences) and front-loaded with the primary purpose. It efficiently conveys scope, usage guidance, and key behavioral traits without repetition or fluff. Every sentence contributes meaning.

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?

Given the tool's complexity (8 parameters, nested objects) and that an output schema exists, the description covers all essential aspects: how to use it, when to use it, pagination behavior, geometry default, and data freshness. No critical information an agent needs to invoke 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 schema thoroughly documents all parameters (near, bbox, filters, limit, offset, fields, include_geometry, dataset). The description adds no new parameter semantics beyond what the schema already provides—it references paging but doesn't elaborate on parameter syntax. Thus 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?

The description starts with a clear verb+resource: 'Search one dataset' with attribute filters, location, bbox, and paging. It distinguishes itself from the sibling dedicated tools by providing concrete example queries (zoning, schools, bus stops, dams) that this generic tool covers, making its purpose unambiguous.

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?

It explicitly instructs to use this tool for questions the dedicated tools don't cover and gives examples. It also discloses the data freshness distinction (live parcels vs offline snapshot), which is essential for choosing this tool over specialized ones. No exclusions are listed, but the guidance is clear and actionable.

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 cover read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations by warning that the server has no real-time data and that the guide lists official sources to direct users to. This helps agents avoid incorrectly expecting live data.

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 three sentences with no filler. The core purpose is front-loaded, and the two following sentences provide high-value routing guidance that directly helps correct invocation.

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?

For a one-parameter tool with a fully described enum, output schema, and safety annotations, the description is complete. It covers the primary caveat (no real-time data) and tells agents how to handle common unsure/current-conditions requests.

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 single 'topic' parameter has a self-explanatory enum with descriptions. The description reinforces the real_time_sources topic in its usage guidance but adds no new parameter-level semantics beyond what the schema already provides.

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 states a specific verb and resource: 'Read one of the server's guides (Markdown).' This clearly differentiates the tool from sibling data-access tools like query_dataset or hazards_at_location, since this is the only guide-reading tool.

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 gives explicit when-to-use guidance: call 'about' first if unsure what the server can do, and call 'real_time_sources' whenever current conditions are requested. It does not explicitly name sibling alternatives, but the guidance is clear and actionable.

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?

The description adds meaningful behavioral context beyond the annotations: being inside a zone is the hazard signal, attributes only describe the map, and absence from a zone does not guarantee safety. This directly supports the openWorldHint and helps the agent avoid misinterpreting negative results.

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 three sentences with no filler. It front-loads the core resource and zone types, then adds two crucial interpretive caveats that prevent misuse of the result. Every sentence earns its place.

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?

Given the output schema exists and annotations already convey the read-only, idempotent, open-world nature of the call, the description supplies the remaining decision-critical context: what constitutes a hazard and what absence means. Nothing needed to call 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%, and the input schema already documents address versus lat/lon usage, including that coordinates skip geocoding. The description adds no parameter-level detail beyond 'at a location,' so the baseline score of 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?

The description identifies the specific resource ('California Geological Survey earthquake zones') and enumerates the zone types: Alquist-Priolo fault rupture, liquefaction, and earthquake-induced landslide. It implies a location-based lookup rather than an explicit verb, but the intent is clear and distinguishable from the non-seismic sibling hazard tools.

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 implies the tool is used to check earthquake-related zones at a location, but it does not explicitly say when to choose this over alternatives like hazards_at_location, wildfire_zone, or flood_zone. No when-not-to-use guidance is provided beyond the interpretive caveat about zones.

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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds significant interpretive context beyond those: it clarifies that zones rate hazard, not building risk, and that 'NonWildland is unzoned, not safe from wildfire' – a crucial caveat that prevents misinterpretation. It also states it is not an evacuation map, which is a behavioral limitation. These disclosures add real value beyond the structured annotations and align with them (no 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?

The description is three sentences, each with a distinct purpose: the first states the core function and output, the second clarifies the hazard-versus-risk distinction, and the third provides the NonWildland caveat and the evacuation-map exclusion with a pointer to read_guide. It is front-loaded with the main purpose and every sentence earns its place. No fluff or redundancy.

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?

For a single-parameter location lookup, the description covers the purpose, the output classes, and key interpretive caveats. It does not explicitly describe the output schema structure, but an output schema is present and will carry that detail. It also does not mention geocoding behavior, but the schema does. The only minor gap is that it doesn't explicitly state that the tool returns data for a specific location (though that is implied). Overall, it is nearly complete for an agent to call it correctly.

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% – the input schema already provides a full description of the 'location' parameter, including how to give either an address or coordinates and that coordinates skip geocoding. The tool description itself does not discuss parameters, but since the schema carries the burden, the baseline of 3 applies. The description adds no extra parameter-level meaning, so it stays at the 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 description starts with a specific verb-resource pair: 'CAL FIRE Fire Hazard Severity Zone at a location', and immediately clarifies what is returned (nearest zone of each class). It distinguishes itself from sibling hazard tools (flood_zone, seismic_zones) by naming the exact hazard type. The mention of '2025 map' adds temporal precision, and the phrase 'rate the long-term hazard of the landscape, not the risk to a building' further specifies the tool's scope.

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 provides an explicit exclusion: 'Not an evacuation map; for active fires call read_guide("real_time_sources")'. This tells the agent when NOT to use this tool and points to a concrete alternative. It does not explicitly state when to use this tool over other hazard tools, but the purpose is clear enough that the agent can infer it. The exclusion is the most valuable guidance and earns a high score, though a fuller 'use this when...' statement would make it a 5.

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