Suxession — French Inheritance Tax Engine

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

readOnlyHint=true already covers the safety profile, so the description adds genuine extra context: the tool is free ('Gratuit'), the premium boundary for donation-vs-succession analysis, and the 1–5 scenario cap. It does not disclose rate limits or output shape, but the output schema exists, so this is solid.

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?

Three compact sentences, front-loaded with the action and example, followed by the free/premium boundary. No filler, though the premium-scope sentence is dense and slightly detours from the core purpose.

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 nested, multi-field tool with an output schema already defined, the description covers the core action, scope limit, and the free/premium distinction. What it omits (return contents) is handled by the output schema, leaving it nearly complete.

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?

The single top-level parameter is a scenarios array whose nested objects already carry field descriptions in the schema. The description does add one constraint not present in the schema (the '1 à 5' scenario limit), but explains nothing about the scenario fields themselves, so it only marginally compensates for the reported 0% top-level coverage.

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?

States a specific verb+resource ('Compare 1 à 5 scénarios de transmission') with concrete examples (usufruit total vs quart en pleine propriété) and clarifies the second-death inclusion. An agent can immediately tell this is a scenario-comparison tool distinct from the simulation/optimization 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?

Draws a clear scope boundary: it is free, and the 'donation vs succession' projection is explicitly declared premium and out of scope. However, it never names or routes to the sibling tools (simuler_droits_succession, explorer_optimisations) for cases the agent might actually want.

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

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

Annotations declare this is a mutation (readOnlyHint=false) that is non-destructive, so the safety profile is partly covered. The description adds real behavioral value beyond that: it activates premium access and, importantly, the code is forwarded verbatim without normalization — a detail that affects how the caller must pass the argument.

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, zero filler, front-loaded with the action and followed by the input-handling constraint. Every clause earns its place.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description covers purpose, input source, and input handling; it omits what happens on an invalid/expired code or how the premium access is scoped, which would make it fully complete for a mutation tool.

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 0%, so the description carries the burden for the single 'code' parameter. It compensates meaningfully by specifying the code's origin (received after payment) and its handling (transmitted as-is, unmodified), which prevents callers from trimming or reformatting it. It stops short of giving a format or validation rule, so not a 5.

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 — activating premium access ("Active l'accès premium") — which is unambiguous. The sibling tools (comparaison, simulation, estimation) are in an entirely different domain, so distinguishing from them is trivial and no explicit routing is needed.

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?

It states a clear trigger condition: the code received after payment, visible on the confirmation page. That tells the agent when this tool applies and where the input originates. It doesn't name any alternative tool or a when-not condition, but none is obviously available.

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

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

Annotations only declare readOnlyHint=true; the description adds real behavioral value by disclosing what the response does and does not contain (levers never named or quantified), that pricing (99 €, one-time) and a payment link are embedded, and how it connects to the paid reveal. This is meaningful output behavior beyond what annotations 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?

Three sentences, front-loaded with the core action, then response constraints, then the next-step sibling. Each sentence carries distinct information with little waste, though the emphasis styling and pricing aside are slightly promotional rather than strictly functional.

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 present, return values need not be re-explained, and the description still covers the essential behavioral nuance (teaser payload, pricing, reveal path). Combined with full annotation and schema coverage, nothing an agent needs to call it correctly is missing.

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% and the single nested 'situation' object is fully annotated (including the 'cas simple uniquement … renvoi wizard' constraint), so the schema carries the parameter semantics. The description adds no parameter-level detail, making the 3 baseline appropriate.

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?

States a specific verb and resource – estimating the exact potential savings via 25 optimization levers – and explicitly positions itself against the sibling explorer_optimisations, which reveals the levers only after purchase. An agent can tell this free-teaser tool apart from the detail/reveal sibling without opening any schema.

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?

Clear context that this is the free, teaser-stage calculation and that detailed levers come later via explorer_optimisations, establishing a funnel relationship. It stops short of explicit when-not guidance or naming the other siblings (comparer_scenarios, simuler_droits_succession), so it is strong context without full routing rules.

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

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

Annotations carry readOnlyHint=true, so the safety profile is covered, and the description adds real context beyond that: the premium 99 € paywall, the requirement of an active unlocked access, and that implementation must be finalized with a notaire. These are non-obvious behavioral facts an agent needs.

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?

Three compact sentences with the premium/access caveat and return contents front-loaded. The closing notaire sentence earns its place as a workflow caveat rather than filler.

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 present, return values needn't be re-explained, and the access prerequisite is well covered. However, for a nested-object tool the meaning of the required 'code' parameter is left entirely unaddressed in both schema and description, leaving a real 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 coverage is only 50% and the description mentions neither parameter. The 'code' parameter is completely undocumented in both schema and description, and 'situation' is only described via its nested object description (cas simple uniquement). The description does nothing to compensate for the coverage gap.

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?

Names a specific resource (the complete optimizer results / stratégies d'optimisation complètes) and states what it returns (leviers, montants, articles CGI, avertissements). It is distinguishable as the 'complete' optimizer output, but it never explicitly contrasts itself with siblings like estimer_economie_optimisation or comparer_scenarios, so an agent must infer the boundary.

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?

Explicitly states the prerequisite ('nécessite un accès actif déverrouillé via deverrouiller_acces'), naming the sibling that must be called first — genuinely useful routing guidance. It stops short of stating when to prefer this over estimer_economie_optimisation, so it lacks an exclusion condition.

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

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

readOnlyHint=true already tells the agent this is a side-effect-free read, so the bar is lower; the description still adds that the result contains "droits par héritier + articles CGI de référence + liens guide" and that the call is free and accountless, which is useful non-obvious context. The main limitation — that only simple cases are handled — is present but only as the terse "cas simple" tag.

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?

Three short sentences, front-loaded with the purpose, then outputs, then access conditions. Dense and mostly waste-free, though "Gratuit, sans compte" is closer to marketing than agent-relevant behaviour.

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?

An output schema exists so return values need not be spelled out, annotations cover the safety profile, and the schema fully documents the single nested parameter. What is missing is the explicit routing/exclusion statement for complex situations, which sits buried in the schema rather than the description.

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% and the nested situation object documents each field (patrimoine, passif, conjoint, option_conjoint, régime_matrimonial), so the schema carries the semantics. The description's enumeration of fields adds little beyond it, 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?

"Calcule les droits de succession français (cas simple)" is a specific verb+resource with an explicit scope qualifier, and the description names the input domains (patrimoine, conjoint, enfants, régime matrimonial) plus the output shape. It does not, however, contrast itself with siblings such as comparer_scenarios, so differentiation must come from the tool name alone.

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?

"cas simple" signals a boundary, and "Gratuit, sans compte" clarifies the access context, but the actual when-not guidance (assurance-vie, donations, démembrement, SCI → renvoi wizard) lives in the schema's nested object description, not here. No explicit routing to comparer_scenarios or the optimisation siblings.

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