Criora climate risk

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

Annotations already establish readOnly, idempotent, non-destructive, and a closed-world scope, so the safety profile is covered. The description adds genuine behavioral value by disclosing the composite nature of the result (this week's daily risk, nearby events, exposure headline set, country profile), which tells the agent this is an aggregating call rather than a single-dimension query. It does not mention latency, rate limits, or data staleness.

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 sentences, front-loaded with the core claim, and the long parenthetical enumeration of climate exposures is informative rather than padding. The listing is dense but each item clarifies scope, so it largely 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?

An output schema exists, so the description is not obligated to explain return values, and the annotations cover the safety profile. What remains — what the tool aggregates, when to prefer it, and where to go for depth — is fully addressed, leaving nothing an agent needs 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%: place, latitude, and longitude are each documented with type, bounds, and usage notes in the schema itself. The description adds no syntax, format, or precedence detail beyond that, 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?

The description names a specific resource (a place) and enumerates exactly what the aggregate answer contains: daily forecast risk, nearby hazards, headline climate exposures, and the country risk profile. It also contrasts itself with get_climate_profile, so an agent can distinguish it from siblings without opening any schema.

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 best first call for a general question about a location" gives explicit routing guidance and names get_climate_profile as the deeper alternative for climate layers. It stops short of saying when not to use it (e.g., for a single-hazard lookup where get_hazards_near or get_forecast would be leaner), so it is clear context rather than a full when/when-not/alternatives statement.

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, closed-world behavior, so the description's marginal job is interpretation of the results. It delivers that: scores run 0-100 with higher meaning more risk, and ranks are among all countries in the Criora Atlas with 1 being the highest risk. That is genuinely useful semantics beyond 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?

Two short sentences, front-loaded with what is produced, followed by the necessary interpretation of the score and rank scales. Every sentence earns its place with no 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?

Since an output schema exists, the description need not explain return structure, and it correctly focuses on the meaning of the score/rank values. It is nearly complete; it could note behavior for invalid or unknown country codes, but nothing essential to invoking the tool 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 coverage is 100% and the single 'countries' parameter is fully documented in the schema (ISO3 codes or English names, minItems 2, maxItems 10). The description adds no 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 states a specific operation: comparing several countries side by side on overall risk plus each risk dimension, with ranks. That is a clear verb+resource. It does not explicitly name the sibling it contrasts with (e.g. get_country_profile for a single country), so it falls short of the top score.

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 'several countries side by side' — an agent can infer this is for multi-country comparison rather than single-country lookup, but there is no explicit when-to-use/when-not guidance and no sibling named.

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 says 'Geocoding by OpenStreetMap Nominatim', which indicates an external open-world web service. This directly contradicts the annotation openWorldHint=false, which declares the tool's domain of interaction is closed. Per the rubric, a contradiction warrants a score of 1.

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 front-loaded with the core purpose, then usage guidance, then a brief attribution. It is concise, though the ODbL/license line is not essential for tool selection and slightly dilutes focus.

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 an output schema present and full schema coverage, the description does not need to explain return values. It clarifies output ordering ('best match first') and a behavioral nuance about city resolution, which is helpful. The main gap is the unresolved annotation contradiction, but as a description it is largely complete for the call.

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 both parameters are fully documented in the input schema. The description adds no parameter-specific meaning (e.g., it never mentions the limit parameter or query syntax), so the baseline of 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 states a specific verb and resource: 'Resolve a place name or address to coordinates, best match first.' This clearly tells the agent what the tool does. However, it does not distinguish the tool from any named sibling (e.g., assess_place), so it falls 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?

It provides a clear usage context: useful when a name is ambiguous and a candidate must be chosen before calling another tool. It does not state when not to use it or name an alternative tool, so it is clear but lacks 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 declare readOnly, idempotent, non-destructive, so the safety bar is met structurally. The description adds genuine behavioral context beyond that: it warns that values come from a single year named per layer rather than a multi-year normal, and that each value carries its source, year, unit, licence and cell size, which preempts misreading the data as climatological normals.

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 purpose is front-loaded in the first clause, which is good. However, the second sentence is a long noun cascade listing every data layer, which is informative for scope but reads as a dense inventory rather than tight structure. Appropriately sized overall, but not maximally economical.

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?

An output schema exists, so return format needn't be explained, and annotations cover the safety profile. The description is thorough on data scope. The main remaining gap is the absence of routing guidance against sibling tools, but for a read-only lookup tool with a rich output schema this is fairly 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 the schema already documents place, latitude, longitude, and categories. The description adds no syntax, format, or resolution guidance for these parameters (it never clarifies the place-vs-coordinates precedence or the effect of the categories filter). Baseline 3 applies when the schema carries the load.

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 verb+resource ('Long-term climate exposure at a place') and then enumerates exactly which layers are returned (ERA5, CMIP6 projections, sea level rise, flood depth, water stress, drought, aridity, land cover, etc.), so an agent knows precisely what it gets. It does not, however, explicitly distinguish itself from siblings like assess_place, get_forecast, or get_hazards_near, leaving the boundary to inference.

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?

There is no explicit when-to-use statement and no named alternative. The agent must infer that 'long-term' implies use when a historical/projected climate profile is wanted rather than a short-term forecast, but nothing in the text says so or excludes competing tools. This is a clear guidance gap for a tool sitting among six siblings.

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 establish read-only, idempotent, non-destructive, closed-world behavior. The description adds substantial value by specifying the scale ('Scores run 0 to 100; higher means more risk'), the data sources (INFORM Risk Index, ND-GAIN, World Bank), and the ~160 indicator count with year/source/benchmarks. This is rich behavioral context beyond the annotations, though return format details are left to the 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?

Front-loaded with the core purpose, then the return content, then the scale interpretation. Every sentence earns its place with no repetition or filler. The structure moves from identity to detail to semantics efficiently.

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?

An output schema exists, so the description needn't explain return values in full. Combined with annotations covering safety and idempotence, the description provides complete context: what the tool returns, what the optional flag unlocks, and how to interpret the scores. Nothing required for correct invocation 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 both parameters are fully documented in the schema. The description explains that include_indicators=true adds about 160 indicators with values, years, sources, and benchmarks, which enriches the meaning of that flag but does not add syntax or format beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('A country's climate and disaster risk from the Criora Atlas') and enumerates exactly what the profile contains (overall risk score and class, domain scores, income group, region). An agent can distinguish this from siblings like get_climate_profile or compare_countries without opening any schema.

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 by the content description but not explicit. The description does not say when to use this vs get_climate_profile, nor does it mention any prerequisites or alternatives. It hints at a use case through include_indicators but never states when/when-not.

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?

With annotations already declaring readOnly and idempotent, the description adds valuable behavioral detail: the temporal resolution changes (hourly, then 3-hourly, then 6-hourly), the 'partial' day marker, the limited precision of 6-hourly min/max to day seven, and the data source (ECCC GDPS, 15 km cell). It does not mention rate limits or caching but covers output semantics well.

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 front-loaded with the core purpose and then details step resolution and risk classes. It is somewhat long and dense, but every sentence adds useful information without 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?

Given the tool's complexity (time-varying output, multiple risk metrics), an output schema exists so return values need not be explained. The description still adds crucial context on step resolution and data source. It is nearly complete, missing only explicit usage alternatives.

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 all parameters are documented. The description adds context on the `hourly` flag (every step vs daily summary) and `place` behavior, but does not clarify latitude/longitude semantics beyond what the schema provides. 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 clearly states it returns this week's forecast at a place and each day's weather risk, naming specific metrics (temperature, precipitation rate, wind, risk class). It is specific but does not explicitly differentiate from siblings like get_climate_profile or get_hazards_near, which an agent might confuse for weather-risk queries.

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 by the description (get a seven-day forecast), but there is no explicit when-to-use guidance or comparison to alternatives such as get_climate_profile (long-term climate) or get_hazards_near (nearby hazards). The agent must infer appropriateness.

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 read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuine operational context beyond that: per-event-type default radius, a hard 25-event listing cap, and the fact that total/counts_by_type reflect all matches rather than the truncated list.

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 the core purpose in the first clause, then source list, then the two constraints that affect result interpretation. The source enumeration is slightly listy but each item earns its place by telling the agent which event_types are actually backed by data.

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 an output schema present, return structure need not be explained, and the description still flags the 25-event cap and the total/counts_by_type semantics that an agent needs to interpret truncation. Only minor gap is the absence of guidance on place-vs-coordinates resolution and relation to sibling tools.

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. The description goes beyond the schema by explaining that radius_km has a sensible per-event-type default (the schema only states the 1-500 bound) and by naming the event categories that event_types accepts, which the schema already enumerates but the prose reinforces in context.

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?

Names the resource precisely ('disasters and hazards') with temporal and spatial scope ('happening now or recently near a place') and an ordering guarantee ('most severe and most recent first'). The enumeration of sources and event types makes it immediately distinguishable from weather-forecast and climate-profile 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?

Usage is implied rather than stated: 'happening now or recently' hints at the recency window, but there is no explicit when-to-use, no mention of alternatives like get_forecast, and no guidance that find_place may be needed to resolve a place name. Context is inferable but not spelled out.

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