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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description's only added behavioral content is a preview of the returned fields, which restates what the output schema already provides; it does not mention the contribution caps, edge cases, or how the saving is derived.

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 compact sentences with the purpose front-loaded and the cross-reference trailing. The inline returns list is mildly redundant given an output schema exists, but it costs little and does not bury the main statement.

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?

With an output schema, full input schema coverage, and complete read-only annotations, the description only needs to establish purpose, which it does. The remaining gap is routing — it doesn't tell an agent how to choose between this and the ~10 other Swiss finance calculators in the sibling list.

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% — both parameters carry units, bounds, and the CHF cap context (7056 employee / 35280 self-employed). The description adds no parameter meaning beyond that, so the baseline 3 applies.

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 — "Calculate Swiss pillar 3a tax savings" — plus the French alias (3e pilier) to disambiguate the domain. It is clearly separable from nearby siblings like calculate_swiss_lpp and calculate_swiss_income_tax by subject matter, but it never names those siblings or states how the pillar 3a calculation differs from them.

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 only routing information is "See list_bundles for related 'finance-suisse' calculators," which points at a discovery tool rather than saying when this tool is the right choice. There is no statement of prerequisites, when-not-to-use, or which sibling calculator handles an adjacent case.

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