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

Annotations already declare readOnly, non-destructive and closed-world, so the safety profile is covered; the description earns credit by adding behaviour they do not: every claim is traceable to a specific article, what the law leaves to judicial discretion is flagged as such, and the output is stated to be orientative rather than a legal document. The explicit data-handling contract (no personal data requested, returned, or to be typed into the call) is a genuinely useful behavioural rule. It stops short of describing the response shape or how the per-debt breakdown is presented.

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?

Front-loaded with the verb and resource, then deliberately condensed with article citations that let the reader judge depth at a glance. The middle section is one very long run-on clause, and the personal-data warning is stated twice («No pide ni devuelve datos personales» then «No le pidas esos datos»), which is mild redundancy in an otherwise tight description.

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 19-parameter tool with no output schema, the description does the necessary work: it says what the simulation returns (eligibility, exoneration per debt, both routes, treatment of the home, effects, revocation) so the agent can set expectations. The absence of any output-shape or format statement is the remaining gap, though it is modest for a read-only calculator.

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 every one of the 19 parameters, including the debt-class enum and the art. 489 cap aggregation, is already documented in the schema. The description adds only the substantive rule that alimony is never exonerated and that Hacienda/Social Security debts are capped, which indirectly informs how to classify debts. Baseline 3 applies since the schema does the heavy lifting.

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 concrete verb and object: simulate the exoneration of unsatisfied liabilities under the TRLC, and enumerates exactly what the simulation covers (eligibility arts. 486-488, per-debt exoneration art. 489, the two routes, effects and revocation). The sentence «No es un escrito: es una simulación orientativa» explicitly separates it from the escrito_* siblings that dominate the toolset.

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 scope of the simulation implies when to use it, and the «no es un escrito» line tells the agent not to use it to draft a filing, but no alternative tool is ever named for the case where the user actually wants the escrito or the carta_deudas. There are also no stated prerequisites (e.g. what happens if the debtor is not insolvent), so usage is inferred rather than instructed.

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