singapore_query_hawker_closures

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 structurally. The description adds that results include source coverage from a bundled catalog and that metadata should be fetched for current coverage — a useful caveat about data currency — but nothing about pagination limits, ordering behavior, or empty-result handling.

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 substantive guidance (inspect the dataset first, use exact filters/search/sort/pagination) is front-loaded and earns its place. But 'Topic: food.' is filler and the closing coverage/metadata sentence is boilerplate that could be tightened without loss.

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 shapes needn't be explained. Still, for a dataset-query tool the description never says what the records actually contain (closure start/end dates, centre names, addresses) or how it relates to the hawker centre directory sibling, which an agent would need to choose and interpret results correctly.

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

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

At 50% schema coverage, limit/fields/offset are undocumented in the schema, but the description names 'exact filters, column text search, fields, sort and pagination', which maps loosely onto all six parameters. However it adds no syntax or format detail beyond what the schema examples already show for q, filters, and sort, so it partially but not fully compensates.

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: query hawker centre closure dates from NEA, with the dataset ID named. It clearly differs from singapore_query_hawker_centres in subject matter, though it never says so explicitly, leaving the agent to infer the distinction 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?

"Inspect dataset d_bda4... first for filter fields" gives a concrete prerequisite workflow step, which is real guidance. But there is no statement of when to prefer this over sibling tools like singapore_query_dataset or singapore_query_hawker_centres, nor any exclusions, so usage is only implied.

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