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

Annotations already declare readOnlyHint and destructiveHint=false, so the description focuses on what annotations cannot say: the response is text plus a PDF URL, the PDF must be fetched with the same credentials (an auth note), and output is deliberately limited to technical facts with no tax assessment. That last scope caveat is genuinely useful. It does not mention failure modes for an unaccepted client or a broken chain.

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 certificate name and regulatory reference lead, followed by the enumerated payload and the return shape in a single dense sentence plus one clarifying clause. Every element earns its place; it is only slightly run-on and could be broken into two sentences for scanability.

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?

No output schema exists, and the description compensates by describing the return: facts as text plus a PDF URL with a credential hint. For a single-parameter read tool with safety annotations already in place, this covers nearly everything an agent needs; only the behavior for a missing/unaccepted link_id is unaddressed.

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?

With 100% schema coverage, the schema already documents link_id as the id from gestoria_listar_mandantes rather than tenant_id. The description reinforces the 'one accepted client' scoping but adds no format, range, or lookup detail beyond the schema, 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?

States a specific artifact (Certificado de cumplimiento, RD 1007/2023) scoped to one accepted client, and enumerates exactly what it reports: producer/Declaración Responsable, NumeroInstalacion, hash chain counts, last hash, re-verification result, and AEAT submission status. That enumeration makes it distinguishable from generic siblings like gestoria_resumen_mandante, though no sibling is named explicitly.

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 only implied: the reader infers this is the certificate-generation call within the gestoría flow. There is no statement of when to prefer it over gestoria_resumen_mandante or gestoria_revision_mandante, nor any prerequisite such as requiring an accepted mandate.

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