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

Annotations declare this as a non-read-only, non-idempotent mutation, and the description adds useful beyond-annotation context: it returns settlement payments, the total and the group link, and requires the admin link/token. It misses one relevant trait the idempotentHint=false implies — that repeated calls would add duplicate expenses — so it isn't fully transparent about re-invocation risk.

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?

Purpose, examples, returns and limits are front-loaded and each carries information. The only waste is the verbatim bilingual duplication (Spanish then English), which roughly doubles the length without adding content for a given reader.

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 no output schema present, the description carries the return contract (who owes whom, payments to settle, total, group link) and the key preconditions (admin token, names present in group), so an agent has everything needed to call it correctly.

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 100%, so the baseline is 3. The description goes beyond the schema by stating a real business rule the schema omits ('names must be in the group'), and it clarifies the id_admin linkage, though the 'empty entre_quienes means everyone' note merely restates the schema description.

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+resource ('adds an expense to a shared expenses group') and explicitly ties it to the upstream sibling that creates the group (crear_gastos), which is the closest relative among the siblings. An agent can tell this is the post-creation expense-adding step, not group creation or a poll/date tool.

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?

Gives two concrete utterance-style examples ('Ana pagó 60 € de la cena entre todos') that make the trigger conditions unmistakable, plus limits on preconditions. It does not, however, state when to use this versus ver_resultados or crear_gastos, so it stops short of explicit alternative routing.

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