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

Annotations already establish it as a safe, idempotent, closed-world read, so the description is free to spend its words elsewhere — and it does: it discloses the return content (itemised taxes with local names, effective and marginal rate, employer cost, step-by-step workings). Its limits are partly self-disclosed by stating that only six regions and specific regimes are modelled, though it never says what is out of scope (e.g. other deductions or income types).

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 operation and its unit, followed by the output shape and then a coverage list — a sensible ordering with no filler sentences. The second half is a dense enumeration of tax terms that borders on a keyword dump, but each entry carries information for an agent reasoning about which optional inputs matter.

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 10-parameter, single-required-parameter tax calculator with no output schema, the description carries the necessary load: what comes back, which rules are modelled, and which regimes are covered. Missing pieces are secondary — precision/rounding, treatment of incomes outside the listed regimes, and the fact that only six regions exist would be worth one clause.

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 the schema already explains every parameter and its defaults; the description adds little parameter-level meaning. The coverage list (IRPEF brackets, cuneo fiscale, dependent spouse credit, pension, impatriati 50%/60%, assegno unico, municipal exemption) hints at which optional inputs are actually modelled, but it never maps an input to an effect, so it sits at the baseline.

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 a specific verb and resource — take-home pay for an Italian employee from a gross yearly salary under 2026 rules — which is unambiguous. It does not, however, name or contrast with the obvious siblings (gross_for_target_net, employer_cost), even though it lists 'employer cost' as one of its own outputs, so the agent must infer the division of labour.

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 forward direction (gross in, net out) implicitly tells an agent when to use it rather than gross_for_target_net, but there is no explicit when-to-use statement and no stated exclusions. No prerequisites or assumptions (employee only, Italian tax resident, six regions only) are flagged as selection criteria.

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