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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds one meaningful behavioral fact beyond that: results reflect a catalog snapshot as of a date, so counts can be stale relative to live pages. It says nothing about aggregation basis, coverage limits, or whether every agency appears.

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 sentence with the resource and the two breakdown dimensions front-loaded, followed by the snapshot caveat. Nothing extraneous.

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 shape need not be explained, and with no parameters and full annotation coverage the remaining burden is small. The snapshot-date caveat is the key piece of context an agent needs, and it is present; only the relationship to the other catalog listing tools is unstated.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline applies. The description correctly implies it is a whole-catalog aggregate with no filtering options.

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?

Specific verb plus a precise aggregate resource: dataset counts broken out by publishing agency and file format, plus the snapshot date. That is clearly distinguishable from record-level siblings like singapore_lookup_dataset or singapore_query_dataset, though no sibling is named 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 explicit when-to-use or when-not-to-use statement, and none of the nearby catalog tools (list_collections, search_catalog, list_catalog_page) are referenced as alternatives. The 'counts by agency and format' framing implies an overview/statistics use case, but the agent must infer that.

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 covering read-only, idempotent, open-world, and non-destructive behavior, the description adds useful context about using the entire official CSV export, the 64 MiB cap, and the EXPORT_PENDING retry state. It does not cover rate limits or output shape, but the output schema and annotations reduce that burden.

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 compact sentences, front-loads the core operation, and each sentence adds relevant scope or behavior details. There is no redundant restatement of the tool name.

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 tool with annotations and an output schema, the description covers the key data-source behavior and retry condition. It is somewhat incomplete on usage alternatives and optional parameter meaning, but overall sufficient for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It mentions towns and a bounded month interval, but it does not explain the optional flat_type parameter or add much beyond the parameter names and schema patterns.

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: comparing HDB resale prices across towns over a bounded month interval. It also distinguishes the data source from a Datastore page, helping separate it from generic query 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?

It gives some operational guidance by warning that exports may still be processing and saying to retry on EXPORT_PENDING. However, it does not explicitly say when to use this tool instead of sibling query tools such as singapore_query_hdb_resale or singapore_query_dataset.

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, open-world behaviour, so the bar is lower. The description still adds real operational context: SLA projection parameters are used and no API key is required, which tells the agent this is a local computation with no auth prerequisites. It stops short of noting accuracy limits or valid coordinate bounds.

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, no filler, and the core purpose and units are front-loaded before the secondary detail about projection parameters and keys.

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-value explanation is unnecessary; the description covers datum, units, scope and auth. Missing only boundary behaviour and the coordinate-order convention for the WGS84 input direction, which matter for a transformation tool but are secondary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the weight, and it does disambiguate the otherwise opaque 'x'/'y' as easting/northing in metres and ties 'from' to the direction of conversion. It does not spell out the axis order for the reverse case (whether x becomes longitude or latitude), which leaves one gap given the zero schema coverage.

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?

Specific verb (convert) plus both resources and formats: SVY21 easting/northing metres and WGS84 longitude/latitude, with a geographic scope (within Singapore). Nothing else in the sibling list performs a datum transformation, so the agent can identify it without opening the 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 phrase 'or the reverse' implies direction is controlled by the input, and 'within Singapore' scopes applicability. But it never states when to prefer this over the nearby address-oriented siblings (e.g. singapore_reverse_geocode) or what happens outside Singapore's bounds. Usage is implied rather than prescribed.

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 cover safety (readOnlyHint true, destructiveHint false, openWorldHint true, idempotentHint false), and the description adds real context beyond them: the two-phase initiate/poll state machine that explains the non-idempotent hint, plus the fact that the returned provider URL may expire and that large files are never pulled into the conversation. It does not say how often to poll, how long an export takes, or what a pending poll result looks like.

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 short sentences, front-loaded with the core action, then the required call sequence, then the behavioral caveats. No filler and nothing repeated from annotations or schema.

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-value detail is unnecessary, and the description still flags the key output caveat (expiring download URL). The only gap is operational guidance for the poll phase — retry cadence and what to do with a not-ready response — which matters for a non-idempotent async 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 coverage is 0%, so the description has to carry the parameter burden, and it does the important part: it names the 'initiate' and 'poll' action values and ties them to call order, which the bare enum lacks. The dataset_id parameter (including its required pattern) is left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Start or poll a dataset export') and immediately scopes it to file-format datasets ('CSV/GeoJSON/KML and datasets without datastore support'), which cleanly separates it from the datastore-querying siblings like singapore_query_dataset. An agent can route correctly 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?

'Call initiate once, then poll on later calls' gives an explicit call sequence, which is the main usage hazard for this tool. The suitability clause implies when NOT to use it (datasets with datastore support), but it never names the alternative tool explicitly, so routing still requires inference.

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

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

Annotations already declare read-only, open-world, idempotent, non-destructive, so the safety profile is covered. The description earns credit by adding genuine behavioral context the annotations cannot: an authentication requirement (LTA_ACCOUNT_KEY) and the non-obvious completion semantics ('Complete is true only after an upstream short page'), which warns the agent that a full page does not mean the search is exhausted.

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 tight sentences with no filler, and the core purpose is front-loaded before the auth and pagination caveats. The phrase 'upstream short page' is slightly opaque jargon, but overall the density is appropriate for the amount of behavior being conveyed.

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 values need not be explained, and the auth prerequisite plus completion semantics are covered. However, for a 7-parameter tool with no schema descriptions, the unresolved offset-vs-result_offset question and the phantom 'continuation' token leave a real risk of incorrect invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 7 parameters, so the description must carry them, and it does not. It never explains limit, max_pages, radius_km, or the critical distinction between offset and result_offset. Worse, it describes a 'continuation' handle that does not appear as a parameter in the schema at all, leaving the agent to guess how to resume the scan.

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: 'Search a bounded set of LTA bus-stop pages near WGS84 coordinates.' The bus-stop domain and the coordinate-based search scope are unambiguous. It stops short of naming a sibling (e.g. singapore_find_nearby_facilities or singapore_get_bus_arrivals) that an agent might otherwise confuse it with.

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: the coordinate requirement, the LTA_ACCOUNT_KEY prerequisite, and the 'continuation identifies the next unscanned page' sentence together tell an agent how to drive the pagination loop. But there is no explicit when-to-use/when-not guidance and no named alternative among the many nearby-geospatial and bus 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 cover read-only, idempotent, non-destructive and open-world status, so the bar is lower. The description still adds real behavioral context: a bounded official export of at most 64 MiB, the rule that only Point geometries with validated WGS84 coordinates are considered, and that omitted geometries are counted — all useful for interpreting result completeness.

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 compact sentences with the primary action front-loaded, then the data-scope guarantees, then the negative constraint. No filler and nothing repeated from the schema.

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-value explanation is not required, and the export-size and geometry caveats are helpful. However, an agent still cannot infer from the description that proximity is controlled by radius_km with a 2 km default or how pagination behaves — meaningful gaps for a 7-parameter geo query.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the parameter semantics, and it only partially does. It maps the category set and implies the coordinate validation for latitude/longitude, but says nothing about radius_km (default 2, max 100), limit/offset pagination behavior, or what include_properties changes in the response.

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 set: 'Find nearby' plus an explicit enumeration of the five category types (HDB carparks with live availability, hawker centres, preschools, park and sport facilities). This distinguishes it from pure directory lookups like singapore_query_carpark_directory by flagging 'live availability', though it does not name any sibling outright.

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 category list and by the negative constraint 'No arbitrary download URL input', which implicitly routes URL-based retrieval to singapore_download_dataset. But there is no explicit when-to-use/when-not statement and no guidance on choosing between this and singapore_get_carpark_availability for live data.

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 safety (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely new behavioral context: matching is deterministic keyword-based (not semantic), and results are suggestions rather than computed facts — an important reliability caveat an agent would otherwise not know.

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 short sentences with the core purpose front-loaded and the caveat following immediately. Some redundancy between 'Route an English question' and 'Search catalog with English keywords', which repeats the English-keyword idea twice.

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 and full annotations exist, so return values and safety need not be described. What is missing is the relationship to the many sibling search/query tools and any hint about acting on the suggestions, which leaves the discovery workflow 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 coverage is 0%, so the description must carry parameter meaning. It clarifies that the required parameter is a natural-language English question/keywords, which is useful, but it says nothing about the 'limit' parameter or any length/format expectations.

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: 'Route an English question to tools and datasets.' That is clearly a discovery/routing tool rather than a data fetcher. However, the trailing sentence 'Search catalog with English keywords' blurs the line with the sibling singapore_search_catalog, so the differentiation is not fully crisp.

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?

Use of an English question as input implies the routing use case, and the line 'suggestions are not evidence or computed facts' hints at a first-pass discovery role. But it never says when to prefer this over singapore_search_catalog or singapore_search_statistics, nor does it advise calling the returned tools next.

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 behavior, so the safety profile is covered. The description adds some genuine context: local-date semantics, default-to-latest behavior, and an unusual pagination-token consumption rule. It omits rate limits, error conditions, and what happens on empty 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?

Three short sentences, front-loaded with the resource and unit, which is good. But the final sentence about consuming local offsets before continuing the preserved upstream pagination token is cryptic and poorly integrated, costing clarity per word.

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 values need not be explained. Still, for a seven-parameter tool with weak schema coverage and an unusual pagination token, the description omits enough that an agent cannot confidently choose values for region, area, station_id, or offset/limit interplay.

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 only 14%, so the description must compensate, but it only clarifies the date parameter (Singapore local dates, latest if omitted) and slightly the pagination token. The seven parameters area, region, station_id, limit, and offset receive no semantic explanation in the description, and the schema leaves most of them bare.

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 unit (NEA temperature in degrees Celsius), which distinguishes it from sibling weather tools like singapore_get_rainfall and singapore_get_relative_humidity. However, it does not explicitly say 'retrieve air temperature readings', leaving the verb implicit and giving no sibling differentiation beyond the implicit unit.

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 implies default behavior ('latest if omitted') but never says when an agent should prefer this over singapore_get_forecast_2h, singapore_get_rainfall, or singapore_list_weather_stations. No exclusions or routing guidance are present.

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, open-world and non-destructive. The description adds value beyond them: this is live/real-time data (not cached historical), an API key is required, and a data-format pitfall (leading zeros) is flagged. It still omits freshness/update cadence and any rate-limit behavior.

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 the capability, then the prerequisite and the format caveat. No filler.

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 values needn't be described, and the description covers the essentials: what data, auth requirement, and a format gotcha. The main remaining gap is the unmentioned service_no parameter and the lack of any note on data freshness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning, and it only partly does. 'Bus stop codes retain leading zeros' usefully explains the bus_stop_code format pitfall, but the optional service_no filter is never mentioned, leaving an agent to guess what it does.

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 resource and result set: live next-bus arrivals (ETA, load, accessibility) at a given bus stop. It is distinguishable from singapore_find_nearby_bus_stops by implication, though it never names the sibling to make the split explicit.

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?

'Requires LTA_ACCOUNT_KEY' gives a real prerequisite for invocation. However, there is no statement of when to use this versus singapore_find_nearby_bus_stops (to resolve a stop code first) or the other LTA/carpark/taxi tools, so routing must be inferred.

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 genuinely useful behavioral facts beyond the annotations: only presence of credentials is reported, values are never exposed, and it performs no network I/O. But "No network requests" conflicts with openWorldHint=true, which signals external/open-ended interaction, creating an inconsistency the agent has to resolve. The safety profile from readOnlyHint/idempotentHint/destructiveHint is otherwise consistent.

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 terse sentences with no filler, and the privacy/credential guarantee is front-loaded after the resource statement. The first sentence is a noun fragment rather than a complete statement, which slightly weakens the lead.

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 values need not be explained, and the description covers the key trust concerns (no credential values, no network). It still omits the primary question for a 'capabilities' tool — what exactly is enumerated (data sources? authenticated APIs? enabled tools?) — and offers no placement guidance among many siblings.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a no-argument invocation ('reports only whether...'), which is consistent with the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description frames the resource as "Local configuration and source availability" and mentions reporting whether credentials are configured, which gestures at the tool's purpose. However, it never uses a verb like "returns" or "lists" and never says plainly that it reports available capabilities/sources, so the agent must infer the payload from the name singapore_get_capabilities. The purpose is understandable but not stated crisply.

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 call this versus the ~60 sibling tools (e.g., as a preamble check before singapore_get_sources or the query_* tools when credentials may be missing). "No network requests" implies it is cheap and safe to call eagerly, but the agent is left to derive that routing itself.

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, open-world, and non-destructive behavior, so the safety profile is covered. The description adds that the data is live and lacks coordinates, which is useful, but it does not clarify whether date_time changes the live behavior or how results are ordered.

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 no wasted text. The main purpose is front-loaded, followed immediately by the important coordinate caveat.

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 description covers the core purpose and the coordinate limitation, and output schema exists so return values need not be explained. However, it leaves the date_time parameter ambiguous for a tool advertised as live, which is a meaningful gap for correct invocation.

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?

Only carpark_number is meaningfully referenced in the description; limit, offset, and date_time are not explained. With schema description coverage at 25%, the description leaves most parameter semantics for the agent to infer.

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 resource and scope: HDB/URA carpark live available lots by carpark number. It also distinguishes this tool from the carpark directory by noting that coordinates are not included and must be joined in separately.

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 gives clear usage context for live availability and explicitly names the complementary directory source for locating carparks. It stops short of stating when to query historical or future times, or how to use pagination.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the useful fact that the call returns the collection plus its child dataset metadata, but says nothing about behavior on an invalid or missing collection_id or how deep the child metadata goes. With annotations carrying the safety burden, a 3 fits.

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 filler, and the resource being fetched is front-loaded before the reason for fetching it. It is dense to the point of near-opacity in the phrase 'child dataset metadata', but nothing 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. What remains missing for a one-parameter catalog tool is how to obtain a valid collection_id and what happens if it is wrong, which is the main practical risk an agent faces here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the meaning of collection_id, and it does not — no hint that the id comes from singapore_list_collections or the catalog, and no note that it must be a positive integer. The only context is the word 'collection' in the purpose clause, which leaves a real gap for the single required input.

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 ('Get') and resource ('a collection and its child dataset metadata'), and the mention of child dataset metadata distinguishes it from a flat listing tool like singapore_list_collections. It does not, however, explicitly contrast itself with singapore_inspect_dataset or singapore_list_collections.

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 purpose clause ('to discover related historical series or ACRA partitions') implies when an agent would call it, which is better than nothing. But there is no explicit when-to-use/when-not and no routing to the obvious alternatives (list_collections to enumerate, inspect_dataset for a single dataset), leaving the agent to infer.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuine behavioral context about local timestamp grouping limits and pagination-token continuity, but the phrasing ('preserved upstream pagination token') is too opaque to be reliably actionable.

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?

Only three short sentences and the purpose is correctly front-loaded. However, the trailing two sentences are jargon-heavy and hard to parse, so brevity comes at the cost of comprehensibility rather than earning 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?

The presence of an output schema relieves the description of explaining return values, and it does cover date defaults and pagination continuity. Still, with 7 parameters at 14% coverage, an agent lacks enough to fill in area, region, station_id, or limit confidently.

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 only 14%, so the description must compensate and largely does not: area, region, station_id, and limit are never explained. It does clarify the date default and hints at offset/pagination_token interplay, but the offset wording ('Consume local offsets before continuing...') is ambiguous rather than instructive.

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+resource: 'NEA 24-hour weather forecast', which implicitly distinguishes it from the sibling 2-hour and 4-day forecast tools. An agent can identify the resource and the forecast horizon without opening the 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 only usage-adjacent statement is 'latest if omitted' about the date default. There is no guidance on when to pick this over singapore_get_forecast_2h or singapore_get_forecast_4day, and no prerequisites or exclusions are stated.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuine behavioral context about pagination (preserved upstream token, consuming local offsets), but 'Local limits apply to timestamp groups' is opaque jargon that an agent cannot act on confidently.

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 short and front-loads the resource, which is good. However, the final two sentences are compressed into terse, hard-to-parse jargon whose meaning is not recoverable from the text, so brevity comes at the cost of 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?

With 7 optional parameters, near-zero schema coverage, and a filter-oriented tool, the description should explain what area/region/station_id select and how limit/offset interact with pagination_token. Output schema exists, so return values need not be explained, but the filtering model remains unexplained.

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 only 14% (only date is documented), so the description carries the burden and largely fails. It clarifies date semantics ('Singapore local dates; latest if omitted') and hints at pagination_token, but area, region, station_id, limit, and offset get no added meaning beyond their names.

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 the resource precisely ('NEA 2-hour area forecasts'), and the '2-hour' qualifier distinguishes it from the sibling 24h and 4-day forecast tools. The retrieval verb is only implied, but an agent can identify the resource without opening the 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?

'latest if omitted' gives one useful default behavior for the date parameter, but there is no guidance on when to pick this tool over singapore_get_forecast_24h or singapore_get_forecast_4day, and no exclusions are stated. Usage is implied rather than directed.

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 safety is covered. The description adds pagination behavior ("Consume local offsets before continuing the preserved upstream pagination token") and a timestamp-group limit caveat, but the phrasing "Local limits apply to timestamp groups" is cryptic and does not clearly state the constraint.

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-loading with "NEA four-day outlook" is good and there is no filler, but the trailing two sentences are dense, jargon-heavy, and harder to parse than they need to be for what they convey.

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 seven optional parameters at 14% schema coverage and no output-schema explanation needed, the description still leaves the area/region/station_id relationship and the actual meaning of the pagination and limit rules unstated. An agent could call it, but not confidently filter by location.

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 14% — only date is documented — so the description carries the burden. It clarifies date default and hints at limit/offset/pagination_token coupling, but says nothing about area, region, or station_id, which are three of the seven parameters, leaving the filtering model unexplained.

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?

"NEA four-day outlook" names a specific resource and time horizon, and the tool name confirms it returns a forecast. It does not, however, distinguish itself from the sibling forecasts singapore_get_forecast_2h and singapore_get_forecast_24h, so the agent must infer the difference from the name alone.

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 only usage-adjacent statement is "latest if omitted" for the date, which describes a default rather than when to choose this tool. There is no mention of when to prefer the 2h/24h forecasts or what the tool is unsuitable for.

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 the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely useful behavior beyond them: results are ordered latest-years-first, null values are preserved rather than dropped, and no authentication key is required. It does not discuss pagination behavior or response shape, keeping it just short of a 5.

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 terse clauses, each carrying distinct information (scope, ordering/null behavior, source caveat and access). The comparison capability and source scope are front-loaded; no sentence is filler.

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 values need no explanation, and annotations cover safety. But for a 6-parameter tool with 17% schema coverage, the description leaves the year-range and pagination parameters entirely to schema inference, which is a visible gap for a historical time-series query.

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 only 17%, so the description must compensate, and it does so only partially: it clarifies that compare_countries takes up to five ISO3 codes and that indicator is a World Bank series. The four pagination/year parameters (page, limit, from_year, to_year) receive no explanation beyond their self-evident names, and curated alias vs. raw code semantics are left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: fetch a World Bank historical indicator for Singapore, with an optional cross-country comparison. The mention of differing definitions/publication lag versus SingStat implicitly carves out space from the sibling statistical tools, though it never names an alternative outright.

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?

Implies when this tool is appropriate (World Bank-sourced historical series, optionally multi-country) and that no API key is needed. However, it gives no explicit when-not guidance and does not name singapore_get_statistics or singapore_list_indicators as the sibling to use for alternative cases, leaving routing to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds real behavior beyond that: the default-to-latest rule, the fact that local limits apply per timestamp group, and that the pagination token is a preserved upstream token whose offsets must be consumed first. That extra context is genuinely useful but phrased cryptically and never explains the return shape.

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 short sentences, front-loaded with the metric and unit, which is good. But the final sentence about 'consuming local offsets before continuing the preserved upstream pagination token' is dense and ambiguous, costing more comprehension than it saves.

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 values needn't be explained, and annotations cover safety. Still missing for a 7-parameter filter tool: how area/region/station_id relate, what valid values look like, and how the offset interacts with the pagination token when resuming.

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?

With only 14% schema description coverage, the description must carry the load, and it partially does: it clarifies that dates are Singapore-local, that omitting date yields the latest reading, and it touches limit/offset/pagination_token semantics. However, area, region, and station_id — three of seven parameters — get no explanation at all, and their interplay is unstated.

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 specific resource and unit ('NEA PM2.5 (micrograms per cubic metre)'), which clearly distinguishes it from siblings like singapore_get_psi or singapore_query_air_quality_annual. It lacks an explicit verb ('retrieve/fetch'), but the resource is 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?

'Latest if omitted' hints at the default-date case, but there is no guidance on when to pick this tool over singapore_get_psi or the annual air-quality query, and no statement of which filters (area vs region vs station_id) to prefer. The pagination sentence describes mechanics rather than when-to-use.

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 a safe, read-only, idempotent, open-world read, so the safety profile is covered. The description adds genuinely new behavior — default-to-latest semantics, local-limit scoping over 'timestamp groups', and an instruction to advance local offsets before reusing the preserved upstream pagination token. However, the last two sentences are jargon-heavy and an agent cannot confidently act on 'local limits apply to timestamp groups'.

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 one clean sentence and there is no filler. The two trailing sentences are compressed to the point of ambiguity, so they cost readability without delivering a clear instruction.

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 values need no explanation, and annotations cover the safety profile. Against that, this is a seven-parameter tool with almost no schema documentation, and the description leaves the most ambiguous selectors (area vs station_id vs region, and limit) undefined.

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 only 14% (just `date`), so the description carries most of the burden, yet it clarifies only the date/latest behavior and the offset/pagination_token relationship on a second read. Nothing explains `area`, `station_id`, or `limit`, including how station_id relates to region or that limit defaults to 20 with a max of 100.

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 opening clause names a specific resource (NEA PSI) plus the pollutants it covers and the regional breakdown, which is more precise than the bare tool name. It implicitly separates itself from the single-metric siblings (singapore_get_pm25, singapore_get_air_temperature) but never names one 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?

Only 'latest if omitted' gives real usage context, telling the agent that no date means current readings. There is no statement about when to prefer this over singapore_get_pm25 or singapore_query_air_quality_annual, and no exclusions or prerequisites, so routing must be inferred.

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 safety is covered. The description adds useful context (mm unit, latest-when-omitted default) plus a cryptic pagination caveat ('consume local offsets before continuing the preserved upstream pagination token') and 'local limits apply to timestamp groups' that hint at behavior without really clarifying it.

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 short and front-loads the resource, but the final sentence is jargon-laden and hard to parse, spending words without conveying a clear instruction.

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 7 parameters, 0 required, and near-zero schema coverage, the description should explain the geographic filters and pagination contract. An output schema exists so return format need not be covered, but the filter semantics and the pagination-token/offset relationship are left ambiguous.

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 only 14% — only 'date' is documented — so the description carries the burden and largely fails to. area, region, and station_id are never explained (mutual exclusivity? granularity?), and limit/offset/pagination_token interactions are only alluded to in opaque terms.

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 data resource (NEA rainfall measured in mm), which cleanly separates it from the weather siblings such as singapore_get_air_temperature or singapore_get_wind_speed. The verb is only implicit through the tool name, but the resource and unit are 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 only usage-adjacent statement is 'latest if omitted', which describes a default rather than when to choose this tool. There is no comparison to sibling weather endpoints or any statement about prerequisites or when not to use it.

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, open-world behavior. The description adds pagination-related context about consuming local offsets and preserving an upstream pagination token, but the wording is vague and omits other behavioral details such as rate limits or auth requirements.

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 short and front-loads the data type and unit. The final sentence about local offsets and the preserved upstream pagination token is concise but cryptic, slightly reducing structural 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 a seven-parameter weather query with low schema description coverage, the description is incomplete. It covers date defaults and some pagination behavior, but does not explain most filters or when to use this tool versus related weather 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 description coverage is only 14%, so the description must compensate for undocumented parameters. It clarifies the date parameter and gestures at pagination token usage, but leaves area, limit, offset, region, and station_id largely unexplained.

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 NEA humidity with a percentage unit, so an agent can infer it retrieves humidity data. It does not explicitly distinguish this weather tool from sibling weather tools such as singapore_get_air_temperature or singapore_get_rainfall.

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 gives useful date semantics ('Singapore local dates; latest if omitted') but provides no guidance on when to choose this tool over sibling weather tools. There are no exclusions or selection criteria for alternatives.

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 destructiveHint=false, so the 'reads public information; no account mutation tools' sentence largely restates structured data. It adds modest value by flagging that API key requirements are reported, but says nothing about freshness, coverage of sources, or how keys are presented.

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 the primary action front-loaded and no filler. The second sentence is partly redundant with the annotations but still earns a small place by delimiting server scope.

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 read tool with a full annotation set and an output schema, the description covers what the call returns conceptually (sources, docs, key requirements). Only the relationship to other discovery tools is left unaddressed.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-arg tool applies. The description correctly implies a full listing rather than a filtered lookup.

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 concrete verb ('List') and a concrete resource set: connected official data sources, documentation, and API key requirements. That is more specific than a title restatement, though it does not distinguish itself from discovery-oriented siblings such as singapore_get_capabilities or singapore_find_relevant_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?

There is no explicit when-to-use or when-not-to-use guidance, and no named alternative. The sentence 'This server reads public information; no account mutation tools' is a scope/reassurance note rather than a routing rule, leaving the agent to guess whether to call this or singapore_get_capabilities first.

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 the safety profile (readOnly, idempotent, non-destructive), so the description correctly spends its budget on behavior: units and footnotes are preserved, values stay as strings to preserve missing-value markers, and the 'last N upstream periods per series' truncation is disclosed. What's missing is any note on cost, rate limits, or response size for large tables.

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?

Four tight sentences with the core verb and scope front-loaded and no filler. The density is high but every clause carries information; slight cost is that the pagination note trails after the filtering explanation rather than sitting with parameter guidance.

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, the description need not explain return shape, and the string-values/missing-marker note is a good bonus. However, for a 9-parameter tool with near-zero schema documentation, the gaps around period ranges, series filtering, ordering, and sibling routing leave an agent guessing on several call-shaping decisions.

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 only 11% across 9 parameters, so the description must compensate and only partly does: it clarifies period (one exact upstream value), period_limit (last N periods per series) and series_offset (pagination). It says nothing about order, from_period/to_period, series_limit, series_contains, or the resource_id format, leaving half the surface undocumented in both places.

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 ('Read SingStat time series') plus the distinguishing trait that units and footnotes are retained. It does not explicitly name or contrast with the discovery siblings search_statistics/inspect_statistics, so an agent must infer this is the data-retrieval endpoint.

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 a workflow hint ('fetches table (or one exact upstream period), then filters series locally') and an explicit pagination instruction ('Use series_offset to paginate series'). It never says when to choose this over singapore_search_statistics, singapore_inspect_statistics, or the many singapore_query_* specialized tools, and offers no exclusion guidance.

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

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

Annotations already declare readOnly/idempotent/openWorld safety, so the bar is lower, and the description still adds real context: WGS84 coordinate system, distance-sorted radius filtering, latest-snapshot default, and that results are a bounded sample with a total match count. It doesn't mention rate limits or whether lat/long must be supplied together for radius filtering.

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 tight sentences with the resource and source front-loaded, then filtering behavior, then the coordinate/return contract. No filler.

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 values needn't be spelled out, yet it still summarizes the bounded sample plus total count. For a 6-parameter, all-optional read tool the definition is nearly complete; only the limit/offset and coordinate-pairing semantics are left to 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 description coverage is only 17%, so the description must compensate; it covers radius, date_time, and the WGS84 lat/long pair but says nothing about limit, offset, pagination defaults, or that radius_km only applies when both coordinates are given. Partial compensation earns a 3.

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 ('Available taxi coordinates from data.gov.sg') plus scope details (radius, distance sorting). This is unmistakably distinct from siblings like singapore_get_carpark_availability or singapore_get_bus_arrivals 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 phrase 'Latest unless date_time supplied' gives useful temporal context, implying when to pass a date. However, there is no explicit when-not guidance or named alternative (e.g., convert_coordinates for CRS conversion before passing lat/long), leaving usage largely 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 readOnly/openWorld/idempotent/non-destructive, so the bar is lower, and the description still adds real value by clarifying that image URLs are returned and never fetched by this server — a meaningful clarification given openWorldHint=true. It does not mention pagination behavior (limit/offset) or what happens when both camera_id and coordinates are supplied.

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 short sentences, front-loaded with the payload, and the final sentence (URLs returned, not fetched) prevents a costly misunderstanding. Nothing is redundant.

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 shape needn't be explained, and annotations carry the safety profile. However, with seven parameters and near-zero schema coverage, the description leaves pagination and identifier filtering unexplained, which is a real gap for an agent constructing a 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?

Only date_time has schema documentation (14% coverage), so the description must compensate for six undocumented parameters, yet it only gestures at radius_km and the coordinate pair. limit, offset and camera_id — including how camera_id relates to the radius filter — receive no explanation in either place.

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 specific resource and its payload: traffic camera image URLs, coordinates and timestamps, plus the optional radius filter. It is unambiguous what the tool returns, but it lacks an explicit verb (list/query) and never distinguishes itself from location-oriented siblings such as singapore_query_carpark_directory or singapore_query_lta.

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?

"Optional radius filter" implies a geo-scoped query, but there is no statement of when to choose this tool over the many other Singapore query tools, no prerequisite (e.g. that radius needs latitude/longitude), and no when-not guidance. An agent must infer usage entirely.

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, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely non-obvious behavior: Singapore-local date semantics, timezone-sensitive grouping of limits, and a preserved upstream pagination token that must be carried forward with local offsets consumed first. That is real added context, but the pagination sentence is cryptically worded and the return shape is 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?

It is short and front-loads the resource identity, so it is not padded. But the final sentence ('Consume local offsets before continuing the preserved upstream pagination token') is dense and ambiguous rather than informative, and 'Local limits apply to timestamp groups' is opaque phrasing that costs the reader more than it gives.

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 seven parameters, zero required fields, an enum region, and no schema descriptions, the description needs to carry more weight than it does. The output schema and annotations cover returns and safety, but an agent still cannot tell what area/station_id/region mean or how filtering composes, so the definition is not complete enough to invoke confidently.

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 only 14% – just the date field is documented in the schema. The description only additionally clarifies the date default ('latest if omitted') and vaguely references the pagination_token. Six other parameters (area, region, station_id, limit, offset, and how area relates to region) get no explanation anywhere, which is a substantial compensation gap.

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 ('NEA UV index') and the source agency, which distinguishes it from siblings like singapore_get_air_temperature or singapore_get_rainfall that cover other measurements. However, it never states an explicit verb or scope (single station vs. national, point-in-time vs. series), so the purpose is only implied by the tool name rather than elaborated.

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 says what happens when date is omitted ('latest if omitted'), which is a small usage hint. But there is no guidance on when to choose this tool over the other weather siblings (PSI, PM2.5, forecasts), no required-vs-optional framing, and no exclusions. Usage must be inferred from the name alone.

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 the safe, idempotent, read-only profile, so the description's job is to add beyond that. It does contribute non-obvious behavior about default-to-latest, local-limit grouping, and consuming offsets before reusing the pagination token, but the pagination sentence is cryptic ('timestamp groups', 'preserved upstream pagination token') and never states the return shape or ordering.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and there is no filler, but the middle sentences are denser than they need to be, especially the opaque pagination instruction, which costs clarity for no stated benefit.

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 values need no explanation, and the safety profile is annotation-covered. However, with seven parameters at 14% schema coverage, the description should explain the filtering/identifying parameters (area, region, station_id) to make the tool callable with confidence — that gap remains.

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 only 14% — of seven parameters, only date is documented in the schema. The description clarifies date locality and defaults plus some limit/offset/pagination_token interaction, but says nothing about area, region (the one enum), or station_id, leaving three parameters meaningless to the agent.

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?

Identifies the specific resource (NEA wind direction in degrees) with enough precision to separate it from singapore_get_wind_speed and the other weather siblings. The verb is implicit in the name rather than the description, but the substance is 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?

"latest if omitted" gives a default-behavior hint, but there is no explicit guidance on when to pick this over wind_speed/air_temperature or which filter combination to use for a given question. Usage is only implied by the date/pagination remarks.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds the units convention and a warning about consuming local offsets before reusing the upstream pagination token, but that sentence is jargon-heavy and does not clarify what a 'timestamp group' is or how paging actually behaves.

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 short sentences with the resource and units front-loaded and no filler. The final sentence about offsets and the pagination token is dense to the point of being opaque, which slightly weakens an otherwise efficient structure.

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 values need no explanation, and annotations cover safety. However, for a 7-parameter tool with 0 required params and 14% schema coverage, the description omits how station/region/area narrow results and how the reading set is grouped, leaving real gaps for an agent choosing arguments.

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 only 14% (only `date` is documented in the schema), so the description has to carry weight. It touches date locality, limit/offset interplay and pagination_token handling, but leaves `area`, `region` and `station_id` — the parameters that most affect which readings are returned — completely unexplained.

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 specific resource (NEA wind speed) with units (knots) and source, which clearly separates it from siblings like singapore_get_wind_direction or singapore_get_air_temperature. It never uses an explicit verb, but 'wind speed (knots)' is unambiguous alongside the tool name.

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?

'Singapore local dates; latest if omitted' implies the default behaviour (return the most recent reading) but gives no when-to-use/when-not-to-use guidance or comparison against the other weather-reading siblings. Usage is only inferable.

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 the safe read profile (readOnly, idempotent, non-destructive), so the bar is lowered. The description still adds real behavioral value by stating the result is 'live' metadata and warning that field IDs may be internal and must be mapped via columnMetadata.map/metaMapping — a non-obvious caveat an agent would otherwise trip on.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with no filler; the core purpose is front-loaded and the caveat follows. Efficient, though the field-mapping sentence is dense enough that it slightly blurs the boundary between the two ideas.

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 values need not be restated, and annotations carry the safety profile. However, for a 4-parameter introspection tool with 0% schema coverage, the description leaves pagination (fields_limit/offset) and the include_raw toggle unexplained, which is a meaningful 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 0% and the description explains none of the four parameters: the required dataset_id pattern, include_raw, or the fields_limit/fields_offset pagination pair are all undocumented. The only param-adjacent hint concerns field naming, not the actual inputs, so it fails to compensate for the coverage gap.

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+resource ('Get live dataset metadata, schema, format, coverage and last update'), so the agent knows it retrieves dataset introspection rather than data rows. It does not explicitly differentiate itself from close siblings like singapore_lookup_dataset or singapore_query_dataset, leaving that routing 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?

Usage is only implied: this is the metadata-inspection step before querying, and the trailing note about using metaMapping names 'for datastore filters' hints at a downstream purpose. No when-not condition or named alternative (lookup_dataset, query_dataset) is 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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered and the description correctly does not contradict it. The description adds some value by enumerating the metadata categories returned and by flagging the read-metadata-first workflow, but it says nothing about pagination behavior or limits on the series listing.

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 dense sentence with no filler, and the core intent plus the content list is front-loaded. The trailing 'before reading observations' clause is slightly buried but still earns its place as workflow guidance.

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 and annotations are rich, so return-value and safety explanations are rightly omitted. However, for a four-parameter tool with zero schema coverage, the description leaves include_raw and the series pagination contract unaddressed, which is a meaningful gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so all four parameters must be explained by the description, and it largely is not. 'Table metadata' and 'series' loosely map to resource_id and the series listing, but include_raw and the limit/offset semantics of series_limit/series_offset (defaults, max 100, pagination behavior) are left entirely unexplained.

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 gives a specific verb ('Get') and a well-scoped resource ('SingStat table metadata'), then enumerates exactly what comes back: frequency, units, definitions, notes, series, and coverage. It also implicitly separates itself from the observation-reading siblings via 'before reading observations', though it never names the counterpart tool (e.g., singapore_get_statistics).

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?

'...before reading observations' supplies a clear ordering rule: call this first to understand a table, then go fetch data. That is real usage context, but there are no explicit exclusions or named alternatives, and the reader must infer that singapore_get_statistics is the follow-up tool.

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 behavior. The description adds genuinely useful context beyond that: the data is live/current and the page size is dictated upstream rather than by the caller. It does not mention rate limits or upstream availability caveats, which keeps it from a 5.

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 waste, and the core purpose is front-loaded ahead of the sibling redirection.

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 is low-complexity (one optional parameter) and has an output schema, so return values need not be explained. The description covers its live nature and the upstream page-size constraint, but could say a bit more about pagination limits or freshness for full completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the 'page' parameter meaning. It does explain that pages are upstream-sized, which is helpful for interpreting results, but it does not clarify page numbering, the default, or the 1–10000 range enforced by the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List a current live page of data.gov.sg catalog') and explicitly distinguishes itself from the snapshot-based sibling by the 'live' qualifier. An agent can tell it apart from singapore_search_catalog without opening either 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?

Names the alternative and its condition ('Use search_catalog for fast search of the bundled snapshot'), which implies this tool is for current upstream data. It stops short of an explicit exclusion, such as when not to page through the live catalog, so it is clear but not fully prescriptive.

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 that this is a safe, read-only, idempotent, non-destructive open-world operation. The description adds useful behavioral context by noting that the page is live and that page size is controlled by the provider, which matters for pagination 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 two sentences, front-loaded with the main action and resource, and contains no filler. Every sentence contributes useful 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?

The tool is simple, has an output schema, and has rich safety annotations, so the description need not explain return values or permissions. However, it omits selection guidance relative to sibling collection tools and does not document the page parameter, leaving some gaps for an agent choosing and invoking it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the sole page parameter, so the description must compensate. It mentions a 'page' and provider-controlled page size, but does not explain that the parameter selects the page number or clarify its range/default behavior.

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 gives a specific verb and resource: list data.gov.sg collections and their child dataset IDs. It is clear what the tool returns, but it does not explicitly distinguish itself from sibling tools such as singapore_get_collection or singapore_search_catalog.

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 states what the tool lists but gives no explicit guidance on when to use it versus alternatives like singapore_get_collection or singapore_search_catalog. There are no exclusions or selection conditions beyond the implicit collection-listing purpose.

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, open-world, non-destructive behavior, so the safety profile is covered. The description adds genuine context beyond that — that coverage dates are included and some series are historical — which matters for data currency, but it says nothing about result size, pagination, or what 'curated' excludes.

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 short sentences with the core action front-loaded, so it is efficient. The trailing sentence about the full catalog is the weakest, since it alludes to a sibling without naming it, but overall there is little waste.

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-value detail is not required, and annotations cover the safety profile. However, for a discovery tool in a family with many list/search siblings, the description leaves the agent unsure how topic values are formed and how this differs from list_collections or search_catalog — meaningful gaps that the description should have closed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single 'topic' parameter; the schema only tells the agent it is a string up to 100 characters. The description's 'by topic' confirms the filter's intent but says nothing about accepted values, matching behavior, or what happens when topic is omitted (it is optional). The description does not compensate for the schema gap.

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 gives a specific verb and resource: browse curated datasets (and their tool names) by topic. It hints at the boundary with the broader catalog search, but does not distinguish itself from close siblings like singapore_list_collections or singapore_list_catalog_page, so the agent cannot fully place it in the family from the text alone.

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 full catalog is searchable separately' implies that singapore_search_catalog should be used when a topic-agnostic lookup is needed, but it never names the alternative or states the selecting condition. The mention that some series are historical gives a hint about when this browse view is appropriate, but no explicit when/when-not guidance is provided.

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, so the safety profile is covered. The description adds curated-scope context and a sibling routing hint, but does not add behavioral details such as return shape or pagination. With annotations and an output schema present, this is an adequate but limited contribution.

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 no waste. The scope is front-loaded and the alternative is stated immediately after, making it easy for an agent to parse.

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 listing tool with an output schema and rich annotations, the description is nearly complete: it establishes scope and points to the correct sibling for other indicators. The only minor gap is that it does not explicitly say it returns a list of curated indicator codes, though the tool name and output schema cover that.

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?

There are zero input parameters, so the baseline for parameter semantics is 4. The description does not need to explain parameter meaning, and the empty schema is consistent with the tool taking no arguments.

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 and scope: curated World Bank indicators for Singapore. It also distinguishes itself from the sibling get_indicator tool by noting that other valid indicator codes are handled there. It stops short of explicitly saying it returns a list, but the name and resource description make the purpose clear.

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 routes non-curated indicator codes to get_indicator, giving the agent a clear alternative. It does not spell out the full workflow (e.g., use this to discover curated codes, then query them), but the when-to-use distinction is present.

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