Estados financieros (EEFF) de empresa

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond annotations: it explains that 'El HTML de la CMF viene sin líneas' and that 'la fuente real de las cifras son los PDFs', giving the rationale for using PDFs. It also discloses that markdown mode uses 'pdf-inspector' to convert the audited PDF. No contradictions with annotations.

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 description is three sentences, each earning its place: first states the overall purpose, second details the two modes, third provides a critical caveat about HTML vs. PDF. It is front-loaded with the key information and avoids redundancy. No filler words or repetition of schema parameter names.

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?

The tool has 9 parameters and an output schema, so return values are already defined. The description covers the main mode distinction, the financial statement variants (consolidated/individual, IFRS/NCH), and the underlying data quality nuance. It does not explicitly differentiate from sibling EEFF tools (e.g., historial, filiales, NCH-specific), but the 'pestanía 3' and period focus make it clear enough. Importantly, it reveals the real source of data (PDFs), which is critical for an agent to understand the tool's behavior.

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 78%, slightly below the 80% threshold, so the description should compensate. It does so by explaining the 'modo' enum in detail (documentos vs. markdown) and referencing 'consolidado o individual' (tipo) and 'IFRS o NCH' (norma). It does not describe all parameters, but the schema already covers most (mes, rut, anio, query, max_chars, validar_contable). The description adds meaning to the main mode parameter and confirms the business context for the others.

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 clearly states the tool's function: 'Estados financieros de un emisor (pestanía 3) para un período, consolidado o individual, IFRS o NCH.' It goes on to explain the two modes (documentos and markdown) and their outputs (PDFs vs. Markdown), which distinguishes it from sibling tools like cmf_empresa_eeff_historial or cmf_empresa_eeff_filiales. The verb is implicit but the resource and scope are precise.

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 description provides clear context for when to use each mode: 'modo=documentos: devuelve los PDFs oficiales... modo=markdown: además convierte el PDF original auditado a Markdown'. This gives usage guidance for choosing the right mode. It does not explicitly mention alternatives or when-not-to-use, but the sibling list and the specific 'pestanía 3' reference give enough context for an agent to differentiate.

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