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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety bar is low. The description goes further by disclosing the exact rule set applied (IR barème 0-37%, professional expense caps, CNSS ceiling, AMO, CIMR, family charges of 600 MAD from 2026), which tells the agent what assumptions drive the numbers — valuable, though it doesn't mention rounding, precision, or the currency-conversion caveat beyond the schema's fx_per_eur.

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?

Front-loaded with the core purpose in the first clause, followed by a compact 'Covers:' enumeration — dense but each item maps to a real computation. The single run-on paragraph with two nested parentheses is slightly heavy, but no sentence is filler.

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?

There is no output schema, and the description compensates by naming the returned components (itemised deductions, effective and marginal rate, employer cost, workings). For a 7-parameter read-only calculator with full schema coverage and annotations, this is nearly complete; only sibling disambiguation and precision/rounding behaviour are absent.

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 baseline is 3, but the description adds real meaning: married/children map to family charges of 600 MAD each from 2026, gross_annual interacts with the 78,000 MAD professional-expense threshold, and it notes the bonus exclusion consistent with the schema. It does not explain how spouse_income affects joint taxation or how pension_pct interacts with the CNSS base, leaving some parameter behaviour to the schema.

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?

States a specific verb+resource+scope: take-home pay for a Moroccan employee from a gross yearly salary in MAD under 2026 rules. It also enumerates the outputs (itemised items with local names, effective and marginal rate, employer cost, step-by-step workings), so the agent knows exactly what computation this performs versus the sibling tools.

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 clearly implies usage ('from a gross yearly salary'), which selects it over gross_for_target_net (the inverse calculation). However, it never names any sibling, gives no exclusions, and doesn't state whether to use it instead of employer_cost or compare_with_netherlands for overlapping cost figures — the agent has to infer that from sibling names.

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