singapore_get_carpark_availability

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.