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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds genuine behavioral value: the rate year, that the result is computed band by band, and the specific relief/surcharge rules applied for first-time buyers and additional dwellings.

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

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

A single front-loaded sentence with no filler; jurisdiction, rate year, method, and both special regimes are packed in without redundancy.

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 two-parameter read-only calculator with no output schema, this covers what an agent needs to invoke it correctly. It could add a hint about the return shape (per-band breakdown plus total), but that is a minor gap given the tool's simplicity.

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% but the schema's own descriptions are thin ('Purchase price, GBP', 'Buyer'). The description compensates by explaining what firstTimeBuyer and additional actually mean in tax terms (nil band to £175,000, 8% ADS), which is meaning the enum labels alone do not convey.

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 exact tax (Land and Buildings Transaction Tax), the jurisdiction (Scotland), the rate year (2026/27), and the calculation style (band by band), which cleanly separates it from uk_stamp_duty_england_ni and wales_ltt among the 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?

Jurisdiction and buyer type imply when the tool applies, but the description never explicitly routes the agent away from the England/NI or Wales calculators, nor states eligibility preconditions. Usage is inferable rather than stated.

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