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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses a great deal: the 80% amortizable base, the cross-rate logic, the PS 17.2% cap and the 10,700 € déficit ceiling, the revente reintégration to plus-value (CGI 150 VB III), the stateless design, and the 'BOFiP dédié attendu S2 2026' caveat that the calculation rests on statute only. It even names the hypothese_economie output field. This is rich behavioral context that annotations alone would never convey.

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?

The purpose is front-loaded in the opening clause, which is good, but the block is dense and overloaded with statutory citations, and the source list appears twice (inline parentheticals plus a trailing '(sources: ...)' block). For a single-paragraph description, several fragments could be trimmed without losing agent-relevant meaning.

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, no-output-schema tax simulator, the description is largely complete: it covers the calculational model, assumptions, legal basis, caveats, and hints at returned values (amortissement annuel, économie d'impôt at 1/9/20 years, hypothese_economie). It is close to fully self-sufficient, missing only a fuller sketch of the response shape, which matters more given the absence of an output schema.

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 the baseline is 3, but the description adds genuine cross-parameter meaning: it explains how loyers_annuels + charges_annuelles + interets_annuels combine to produce 'économie RÉELLE' versus the theoretical maximum flagged in hypothese_economie, and how revenu_net_imposable/tmi_pourcentage interact for the TMI. That inter-parameter logic goes beyond the individual schema descriptions.

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 resource (Dispositif Jeanbrun, amortissement du bailleur privé) and verb ('Calcule l'amortissement annuel retenu et l'économie d'impôt'), and scopes the device via its legal window (21/02/2026 → 31/12/2028). It is clearly distinguishable by subject from the fiscal_* siblings, but it never explicitly names a related alternative (e.g. fiscal_foncier_regime or fiscal_lmnp_regime) to route the agent, so it stops short of full sibling differentiation.

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 implied through the eligibility window, the 9/20-year engagement horizons, and the note that TMI is supplied or derived, but there is no explicit when-to-use vs when-not, and no named alternative for closely related regimes. An agent can infer the context but gets no exclusions.

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