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

Goes well past the annotations by disclosing validation behavior: an out-of-catalog value produces an error listing valid options, and a legally forbidden combination (capital below minimum, two-member board in an SL, unanimity in a capital company) refuses to compose and explains why. It also states it calls the same generator and checks as the website and that missing fields appear as bracketed placeholders. What it does not say is what the returned document looks like (plain text, length, structure), which matters given there is no output schema.

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 and the catalog pointer are front-loaded, but the no-personal-data rule is stated twice almost verbatim ("No devuelve ni pide datos de personas..." and then "No pide ni devuelve datos personales..."), and the long parenthetical form list duplicates the enum already in the schema. Tightening the repetition would make it noticeably sharper.

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 and a nested `datos` object, the description covers the important gaps: where to learn field ids, that missing data becomes bracketed placeholders, and how errors are reported. The one omission is any indication of the produced artifact's format or size, which an agent might want before dumping the result.

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 earns more by explaining cross-parameter consequences the schema cannot — invalid catalog ids error out with the list, decisions unsupported by the chosen form are silently ignored, and unfilled `datos` fields surface as bracketed gaps. That tells the agent how to compose `forma`, `decisiones` and `especialidades` together.

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?

Opens with a specific verb and resource ("Compone los estatutos completos") and enumerates the scope: numbered articles plus a table of precepts, across the forms in the catalog. It also names the sibling `catalogo_formas_estatutos` as the discovery tool, so an agent can tell the two apart immediately.

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 an explicit prerequisite ("Lée las formas, sus campos, sus decisiones y sus modalidades con `catalogo_formas_estatutos`") and an explicit prohibition (do not ask for or write personal data, those are bracketed holes). It stops short of stating when *not* to use it beyond that, e.g. whether it suits only full statutes vs. partial clauses.

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