Rising Shores Singapore

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

Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral content by stating what the answer includes ('the first rise at which the area is reached'), which matters since no output schema exists, but it is silent on defaults, return format, and 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?

It is a single compact sentence, but it is grammatically incomplete (a noun phrase missing a leading verb), which costs clarity. Nothing is padded, but the front-loading is undermined by the broken construction.

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 six parameters, full schema coverage, and no output schema, the description should at least clarify the computed result and route the agent among the many flooding siblings; it partially describes the result but omits sibling differentiation and says nothing about storm_surge, lang, or defaults.

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 parameters are already fully documented (including rise_m-vs-year/scenario and the scenario enum). The description only echoes the 'sea-level rise or a year and scenario' trade-off, adding no syntax or default detail beyond the schema. 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 identifies the resource (one planning area) and the two outputs (residents in flooded parts at a given rise/year-and-scenario, and the first rise that reaches the area), which is more specific than the bare tool name. However, it is a verbless fragment rather than a clear action statement, so the agent must infer that this is a query returning a computed result.

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 guidance on when to use this tool versus siblings such as flood_impact, most_affected_areas, when_does_it_flood, or list_areas. The 'one planning area' phrasing hints at scope, but no conditions, exclusions, or alternatives are 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?

Annotations already declare readOnlyHint and openWorldHint, covering the safety profile. The description adds a useful honesty caveat ('roughly when each scenario gets there'), but says nothing about data sourcing, model assumptions, or geographic limits beyond the Singapore framing.

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?

A single front-loaded sentence that states the input domain first and then the output, with no redundant or filler text.

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 takes on the burden of describing the return value, and it does so adequately (threshold sea-level plus per-scenario timing). Some methodological caveats are missing, but an agent has enough to call and interpret the tool.

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 query format and the lang enum are both fully documented in the schema. The description adds no syntax or format detail beyond what the schema already provides, 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?

Names a specific input (Singapore postal code or place name) and a concrete output (sea-level rise at which the location first connects to the sea, plus rough timing per scenario). The purpose is unambiguous, though it does not distinguish itself from near-siblings like flood_impact or when_does_it_flood.

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 input constraint ('For a Singapore postal code or place name'), but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative among the many flood/sea-level 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?

The readOnlyHint and openWorldHint annotations already declare this is a safe, self-contained lookup, so the safety burden is covered. The description usefully discloses what the tool reports (land share, buildings, residents) and the rise-vs-year/scenario input modes, but adds nothing about default behavior, error cases, or data vintage. Adequate with annotations doing the safety lifting.

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?

A single compact sentence with the scope and the output metrics front-loaded, and the alternate input mode kept to a short parenthetical. No waste, though the parenthetical slightly interrupts the main clause.

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 read-only, zero-required-parameter aggregation tool with a fully documented schema and no output schema, the description supplies the key missing piece: what the returned figures represent. It needn't explain return format, and only the absence of sibling routing keeps it from a 5.

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 enum values and the default scenario and lang documented inline, so the schema carries parameter semantics fully. The description's mention of rise_m vs year+scenario mirrors what the schema already says and adds no syntax, units, or range detail beyond it. Baseline 3 is correct.

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 resource (island-wide flood impact for Singapore) and enumerates the computed metrics: share of land flooded, buildings reached, residents affected. The 'island-wide' scope contrasts with the area-level sibling area_impact, though no sibling is named explicitly, so it stops 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?

The parenthetical '(or a year and scenario)' hints at two input modes, but the description never states when to prefer this over area_impact, most_affected_areas, places_underwater, or check_address. No exclusions, prerequisites, or alternative-selection guidance are given.

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 openWorldHint=false, so the safety profile is covered. The description adds that the list is fixed at 55 entries with population data, which is useful context, but says nothing about caching, ordering, or whether the language parameter changes the area keys themselves.

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?

One front-loaded sentence that names the count, the domain, and the payload with zero filler. Nothing could be removed without losing information.

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-required-parameter reference lookup with no output schema, the description adequately conveys what comes back (areas with populations). Return field names are unspecified, but for a simple enumeration this is a minor gap.

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 single 'lang' parameter already documents the en/fr enum with a default, so the description carries no additional parameter burden. 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 resource and content: the 55 URA planning areas that the impact tools accept, plus resident populations. An agent can tell this is a reference/enumeration lookup rather than a computed impact result. It does not explicitly name the sibling it contrasts with (area_impact, most_affected_areas), so it stops 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?

The phrase 'the impact tools accept' implies this list is an input-reference for the other tools, which gives helpful implied context. However, there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. area_impact), so the guidance is only implied.

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 openWorldHint=false, so the safety profile is covered. The description usefully adds that the result is a link (a URL artifact) rather than raw data, but it does not disclose the link's form, whether it is shareable, or how the mutually exclusive parameters interact at runtime.

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?

A single tight sentence with no waste, front-loading what the tool returns. It is efficient, though the parenthetical could be marginally clearer about the alternative-input form.

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 link-generating tool, the key missing context is what the returned link looks like and how it should be relayed to a user, which matters since there is no output schema. The description is adequate but leaves the return artifact underspecified.

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 language, year, rise_m, scenario, and storm_surge. The description only paraphrases the rise-versus-year-and-scenario choice that the schema's 'instead of rise_m' note already conveys, adding no new semantics beyond structured fields.

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 concrete output (a link) and the resource state it encodes (the Rising Shores map with sea raised), so an agent can tell it produces a shareable map URL rather than performing analysis. It does not, however, explicitly contrast itself with analysis siblings like sea_level or flood_impact, leaving differentiation implicit.

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 statement of when to use this tool versus the many siblings (sea_level, area_impact, flood_impact, etc.). The agent must infer that this is for generating a link rather than retrieving data. No exclusions or preferred conditions are given.

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 openWorldHint=false, so safety and scope are covered. The description adds the counting semantics (residents inside flooded areas) but says nothing about output ordering, tie handling, or defaults; with annotations carrying the safety profile, this is adequate but thin.

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?

One sentence with no wasted words and the ranking metric stated up front. The parenthetical '(or a year and scenario)' is slightly compressed and could be clearer, but the structure is efficient.

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 six-parameter, no-output-schema tool the description leaves the agent to infer the return shape (ranked list, count) and the mutual exclusivity of rise_m and year/scenario from the schema alone. Nothing is actively wrong, but the description does not fully close the gaps that the missing output schema creates.

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 each of the six parameters is already documented, including the rise_m vs year+scenario alternative and the n/lang defaults. The description merely gestures at the 'sea-level rise (or a year and scenario)' modes without adding syntax or interaction detail beyond the schema, so 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 the resource (planning areas) and the ranking criterion (most residents in flooded areas under a given sea-level rise/year/scenario), which is specific enough to separate it from list_areas and plain area lookups. It is a noun phrase rather than an explicit verb, and it never names the closest siblings (area_impact, flood_impact) to disambiguate.

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?

No when-to-use or when-not-to-use guidance is given, and no alternative is named. This is a real gap because siblings area_impact and flood_impact overlap heavily with a ranked-areas query, and nothing tells the agent 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond the structured fields — nothing about defaults, projection semantics, or how rise_m/year/scenario interact — so it contributes little on top of 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?

A single front-loaded sentence with no filler, and the resource plus optional filters are stated immediately. It is efficient, though the awkward 'at a rise' phrasing costs a little clarity.

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 an 8-parameter tool with no output schema, the description is thin: it never explains that results are scenario-based projections or how scenario, year, rise_m, and storm_surge combine. The schema param descriptions cover much of that gap, so it is adequate but leaves the overall scenario model implicit.

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 88%, so the schema already documents area, lang, year, limit, rise_m, scenario, and storm_surge. The description's 'of one kind or in one planning area' merely restates the kind and area filters and adds no syntax or interaction detail (e.g. year vs rise_m). 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?

The description names a specific resource — named public places (hawker centres, schools, places of worship) — and the condition that reaches them (sea-level rise), so an agent can infer it lists at-risk places rather than raw flood data. The phrasing 'reached by the sea at a rise' is slightly oblique and no sibling (e.g. area_impact, most_affected_areas) is referenced, so it is clear but not differentiated.

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 clause 'optionally of one kind or in one planning area' is a filter hint, not usage guidance. There is no statement of when to pick this over area_impact, flood_impact, or most_affected_areas, which occupy adjacent territory, and no prerequisites are given.

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 openWorldHint=false, so the safety profile is covered. The description adds genuinely non-derivable context: the value is expressed in metres above today's high-tide level, and the provenance (CCRS V3 2024, Ng et al. 2025, IPCC AR6) signals a sourced, region-locked projection rather than live observation.

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?

A single front-loaded sentence with zero filler. The units and provenance are packed into the same sentence without a separate preamble, and every clause carries information the agent needs.

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 correctly carries the burden of stating what the returned number means (metres above today's high-tide level) and its source. It stops short of explaining how storm_surge alters the result or the valid year range, but those are documented in the schema.

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 schema already documents year, scenario, storm_surge, and lang with enums. The description's phrase 'a year and an emissions scenario' restates the schema rather than adding syntax or constraints, 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 resource (projected sea-level rise at Singapore) with explicit scope (a year and an emissions scenario), units, and data provenance. An agent knows exactly what the tool returns, though it never names or distinguishes itself from sibling tools like flood_impact or when_does_it_flood.

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 when-to-use guidance, no exclusions, and no reference to the overlapping siblings (flood_impact, places_underwater, when_does_it_flood) that an agent might otherwise confuse with a sea-level projection query. Usage must be inferred entirely from the resource name.

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 openWorldHint=false, so the safe read-only nature is covered. The description adds that the payload is source/licence/limit metadata, which is useful, but discloses nothing further about format, licensing constraints, or data freshness beyond what annotations 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?

Two short sentences with zero filler; the content list comes first and the imperative usage cue follows. Nothing could be cut without losing 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?

For a simple read-only, single-optional-param tool, the description conveys the content of the response (sources, licences, limits) well enough that a missing output schema is not a real gap. Minor omission: no note on whether results vary by query or are static.

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 optional 'lang' enum is fully documented in the schema, so no description-side compensation is required. Baseline 3 applies since the description adds no parameter-level detail.

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 the resource clearly: provenance ('what the numbers are made from'), licences, and limitations of the data. It has no explicit verb, but the noun phrase plus the sibling set (flood_impact, sea_level, etc.) makes it obvious this is the metadata/methodology tool rather than a data-returning one.

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?

'Read this before quoting any figure' is an explicit, actionable usage directive that tells the agent when to invoke it. It does not name an alternative tool or state exclusions, but the usage condition is 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 this a read-only, closed-world query, so the safety profile is covered. The description usefully discloses the output behavior (a year per scenario, capped at 'beyond 2150'), but says nothing about what 'scenario' refers to or the range/assumptions behind the projection.

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?

A single tight sentence with no filler, and the operative concept (year vs. 'beyond 2150') is front-loaded. It reads as a returned-value fragment rather than a full sentence, but no words are 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?

With no output schema, the description does the work of explaining the return value, which it handles adequately. However, 'each scenario' is never defined, so an agent cannot fully predict the response shape for a 2-parameter tool.

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 and the enum are already documented; the schema even carries the 0-9 bound. The description restates the rise_m meaning ('metres above today's high tide') but adds no syntax or constraint beyond the schema, 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 the resource clearly (year at which a scenario reaches a given sea-level rise) and pins down the return semantics, including the 'beyond 2150' sentinel. It implicitly distinguishes itself from siblings like sea_level and flood_impact, though it never says so 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?

There is no statement of when to use this tool versus sea_level, flood_impact, places_underwater, or the other siblings. The agent must infer usage from the return-value phrasing alone.

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