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

Annotations already declare readOnly=true, idempotent=true, destructive=false, so there is no safety burden here. The description still adds real behavioral value by disclosing that bases are automatically matched to the city's 2026 social insurance/housing fund floor and ceiling and truncated, and that tax uses cumulative withholding, which explains why the month parameter matters. It does not cover rate-limit, data freshness for policy years, or error behavior for unsupported cities.

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 sentences, front-loaded with the core outcome and followed by the computation flow; every clause maps to an actual output component or behavior. It is dense but not padded, though the long second sentence could be broken up for readability.

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 7-parameter tool with nested special deductions, full schema coverage, an output schema, and non-destructive annotations, the description supplies the missing conceptual layer: what is computed end-to-end and how city limits are applied. An agent has everything needed to call it correctly without further explanation.

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%, including all nested specialDeductions fields, so the schema already carries parameter meaning and the baseline is 3. The description's note about auto-matching and truncating bases to city limits largely repeats what socialBase/fundBase descriptions already say, adding only the 2026 policy-year context.

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+resource pair: computing after-tax salary and employer labor cost for a given city, and it enumerates the components covered (social insurance and housing fund deductions for individual and employer, special additional deductions, cumulative withholding tax, net pay, monthly employer cost). This is far more than restating the title, and an agent can tell this is the combined take-home + employer-cost calculator rather than the narrower income-tax or limits-lookup siblings.

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?

Usage is only implied: the description makes clear this is a full take-home/cost simulation for a given pre-tax monthly salary and city, which implicitly suggests using the city-limits or policy-query siblings first if raw data is needed. There is no explicit when-to-use vs when-not, no mention of when to prefer calculate_income_tax alone, and no prerequisites stated.

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