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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds behavioral context the annotations cannot convey: this is a paid call at $0.005 USD, billed via x402 or an API key, which affects whether an agent should batch salaries into one call. It stops short of describing the response shape, which matters given there is no output schema.

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 purpose sentence is front-loaded and efficient, but the standalone "Paid." fragment at the start is redundant with the later "Paid: $0.005 USD per call" sentence, and it pushes the actual purpose out of the first position. The pricing tail is also the kind of detail that could be one clause rather than a full sentence.

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 read-only calculation tool with a fully documented three-parameter schema, the description covers purpose, cost model and the anti-pattern to avoid. What is missing is the return-value contract (per-employee breakdown? totals?) and any note on the rate year behind "UK Rules data" — notable because there is no output schema to fall back on.

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 description coverage is 100%, so every parameter (date, employees, apply_employment_allowance) is already documented in the schema with patterns, ranges and defaults. The description only echoes "one or more annual salaries on a date" and adds no new semantics such as what date is used for the rules lookup or how allowance eligibility is decided. Baseline 3 is appropriate.

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 gives a specific verb and resource ("Calculates employer Class 1 National Insurance") plus scope ("one or more annual salaries on a date using UK Rules data"). None of the siblings (get_rate, check_uk_business, search_rules, etc.) overlap with this computation, so no disambiguation is needed and an agent can route on the description 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?

The line "Use this instead of doing the maths yourself" gives a clear directive against manual computation, which is real guidance. However, it never contrasts this with the obvious siblings an agent might otherwise reach for, such as get_rate or search_rules for NI rates and thresholds, and it states no preconditions about which tax year the supplied data covers.

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