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

The annotations already mark the tool as read-only, idempotent, and non-destructive, so the description's job is to add behavior beyond safety. It discloses the return output ('tax due and the effective rate'), the first-time-buyer relief threshold up to £500,000, and the £40,000 threshold for additional properties. This adds meaningful behavioral context the annotations do not provide.

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 compact and front-loaded: core action and jurisdiction first, then buyer-type details, return values, units, and jurisdictional exclusions. Every sentence contributes useful information, and the source URL is a minor but acceptable addition.

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?

Given the complete annotations, fully described parameters, and presence of an output schema, the description covers all necessary calling context: eligible jurisdiction, buyer types, price units, return values, and excluded regions. The specific SDLT rate bands are omitted, but the tool itself calculates those and they would be redundant 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 coverage is 100% and both parameters already have descriptions, giving a baseline of 3. The description adds genuine value by explaining the buyer enum semantics in detail, including relief thresholds and the higher-rates threshold. It also confirms that amounts are in GBP, reinforcing the price parameter meaning.

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: 'Work out Stamp Duty Land Tax (SDLT) on a property purchase in England and Northern Ireland.' It also names the buyer types, making the tool's scope unambiguous. Although there is no direct sibling stamp-duty tool, this is clearly differentiated by jurisdiction and purpose.

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 clearly scopes usage to England and Northern Ireland and notes that 'Scotland (LBTT) and Wales (LTT) have their own rates,' effectively telling the agent not to use this tool for those jurisdictions. It also explains when each buyer type applies. It does not name an explicit sibling alternative, but none close exists among the listed tools.

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