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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description is consistent with a pure offline computation. It adds genuinely useful context beyond the annotations: no authentication is required, the rates are versioned to specific effective dates, and the response shape is 'tier-by-tier breakdown and total'. It does not discuss rate staleness or rounding/caveats, but the burden is lighter given annotations.

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

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

Two dense sentences with the core purpose and rate versions front-loaded, then the return value, then the sibling routing. The final Finch pointer is promotional but earns some of its space as an alternative-use router; it could have been folded into a shorter clause.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter, single-output calculation with full schema coverage and no output schema, the definition supplies what is needed: rate basis and dates, buyer-profile granularity, and the shape of the result. Minor gaps are the property_count ordinal ambiguity and the absence of any caveat about non-residential or non-purchase stamp duty cases.

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

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

Schema coverage is 100%, so all three parameters are already documented, giving a baseline of 3. The description adds the semantic point that ABSD depends on buyer profile and property ownership position, but its phrasing 'how many residential properties the buyer will own' slightly conflicts with the schema's 'which residential property this is for the buyer (1 = first...)', which could mislead an agent about whether property_count is a count or an ordinal.

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

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

Names a specific verb ('calculator') and resource ('Singapore residential property stamp duty') and enumerates exactly which duties are computed (BSD from 15 Feb 2023, ABSD from 27 Apr 2023), plus the buyer-profile dimension. An agent can immediately distinguish this from analyze_singapore_condo or any market-analysis sibling.

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?

Establishes the operating context (free, no-auth, statutory IRAS rates) and implicitly routes price/rent/yield questions about a specific condo elsewhere. It does not state explicit exclusions (e.g. non-residential property, leasehold/stamp duty on rentals) or say what to do outside its scope, so it falls short of a full when/when-not statement.

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