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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the scope note that this is Italy-specific and that its options mirror net_salary. It does not disclose whether the result is an exact statutory computation or an estimate, nor whether the gross figure includes the bonus, which is the kind of context that would matter for a payroll calculation.

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?

Two short sentences with the core definition front-loaded and the use case second. There is essentially no waste. "The same situation options as net_salary" is slightly vague phrasing, but it earns its place as a cross-reference.

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 an 11-parameter calculator with a fully documented schema and no output schema, the definition covers the essentials of what it computes. However, with no output schema the description should say what comes back (a single gross figure or a breakdown) and whether the answer is exact or approximate. Those omissions are the main completeness gap.

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 all 11 parameters including enums for region and period are already documented with defaults. The description contributes only the meta-signal that the option set matches net_salary. It does not, for example, clarify that bonus_annual and pension_pct affect the gross figure rather than the net target, which would have added real value beyond 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?

The description states a specific inverse calculation: the gross yearly salary in Italy that produces a given take-home figure. This clearly distinguishes it from the sibling net_salary (which goes the other direction) and from employer_cost. It stops short of naming net_salary as the explicit reverse operation, so the differentiation is implied rather than stated.

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?

"Use it to set a salary ask or check an offer" gives a use context but no explicit when-not condition or named alternative. The clause "same situation options as net_salary" points at a sibling but functions as a parameter hint rather than routing guidance. An agent can infer the inverse relationship, but the description never says it outright.

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