mi-sii-mcp

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

Beyond the annotations, it discloses the hard output caps (200 filas, 40000 caracteres), the single-statement restriction, that the query runs against a copy of local data rather than production, and the literal-only constraint. These are exactly the operational facts an agent must know to avoid failing or over-scanning.

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?

Three dense sentences: what it runs, the prerequisite tool, then the limits and tuning advice. No repetition of the title or the schema, and the most important constraint (solo lectura, una sola sentencia) is front-loaded.

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, the description compensates by stating the row/character caps and pointing to datos_esquema for table and column semantics. Minor gaps remain: it doesn't name the SQL dialect or note error behavior for an invalid statement.

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% and documents the sql string itself, but the description adds a real constraint not in the schema: no bind parameters — values must be written as literals. That is meaningful extra semantics for the only parameter.

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 verb (ejecuta), a precise resource (una sola sentencia SELECT/WITH … SELECT de solo lectura) and enumerates the datasets it can reach (RCV, F29, boletas, F22, hallazgos, bitácora). It is clearly distinguishable from siblings like rcv_documentos or f29_historial, which are fixed-shape readers rather than free queries.

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 ("Llama antes una vez a datos_esquema") and guidance on how to keep queries cheap (filter by RUT and período, agrupa o usa LIMIT). It does not say when to prefer a sibling tool over free SQL, so no full when/when-not routing is present.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context: that this is a one-shot orientation call whose output is interpretation rules, not just a DDL dump. It doesn't state the response format or size, so not a 5.

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?

Two sentences, no filler. The content scope comes first and the action directive (call once, before queries) is front-loaded at the end where it reads as the takeaway. Every clause names a concrete artifact (montos, notas de crédito, RCV, F29).

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, so the description carries the burden of previewing the return value — and it does, listing tables, columns, types, meanings and domain interpretation rules. For a no-argument orientation tool, nothing an agent needs before calling it is missing.

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?

Zero parameters, so the baseline is 4; there is nothing a description could add on parameter semantics. The description correctly spends no words on inputs.

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?

Specific verb ("describe") and resource (the tables behind consulta_sql), plus an enumeration of what the output covers: column types and meanings, amount/credit-note/RCV/F29 interpretation rules, and data-absence handling. It explicitly anchors itself to the sibling consulta_sql, so an agent can tell it apart from the query tool without opening a schema.

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?

"Llámala una vez antes de escribir consultas" gives a clear when (before authoring queries) and a cardinality constraint (once, i.e. idempotent, matching the annotation). No explicit when-not or named alternative beyond the implied consulta_sql reference, which keeps it short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by explaining that honorarios retention (código 151) is included only when that month's received honorarios boletas were synchronized, which the annotations do not convey.

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 a single dense sentence that front-loads the per-month scope and then lists the returned fields. It is efficient for the information conveyed, though the conditional clause makes it slightly heavy to parse.

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, the description does a reasonable job explaining returned values, including the conditional honorarios retention. However, it omits what happens for months where no F29 is present and does not distinguish the tool from f29_releer, leaving gaps for correct tool selection.

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%, so rut and the AAAA-MM period formats are fully documented in the schema. The description adds no further meaning about how desde/hasta bounds are treated or whether the range is inclusive, so the baseline of 3 is appropriate.

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 makes clear that this retrieves a per-month F29 history for a date range, listing presentation status, folio, debit/credit amounts and total payable. It is specific about the returned data but does not explicitly contrast itself with nearby tools such as f29_releer.

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?

There is no guidance on when to use this tool instead of alternatives like f29_releer or iva_resumen. The only implied usage is the presence of required rut/desde/hasta parameters, which is not the same as usage guidance.

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

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

Annotations already declare readOnlyHint=false and idempotentHint=true; the description adds that it updates saved values, that a mismatched reading will not overwrite a good saved one, and that no range means all months. This adds meaningful mutation and safety context beyond the annotations, though it omits return and error details.

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?

Three sentences, front-loaded with purpose, followed by the safeguard and then usage/default behavior. Each sentence contributes distinct information with no filler.

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 moderate-complexity local re-read tool with full schema descriptions and rich annotations, the definition covers purpose, triggers, default scope, and safety semantics. It does not describe return values, and there is no output schema, leaving a small but real gap.

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 rut/desde/hasta parameters are already well documented. The description adds the non-obvious default that omitting desde/hasta re-reads all saved months, which is useful semantic context beyond the schema.

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 verb 'relee' and resource 'PDF del F29 guardados', and explicitly contrasts with 'sin ir al SII', so an agent can distinguish it from SII synchronization tools. It also clarifies the effect: re-reads each folio's PDF and updates values if they change.

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 explicit triggers: after updating mi-sii-mcp or when a saved F29 reading does not reconcile. It also states the default scope ('sin rango relee todos los meses guardados'), though it does not explicitly name a sibling alternative.

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

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

Annotations already cover the safe read-only profile, and the description adds important context: mi-sii-mcp does not store these public data and the tool does not go to the SII. It also explains what the tool returns (where to consult and what to search, plus the F22 rule when regla=true), though it does not discuss data freshness or update cadence.

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 dense but front-loads the core distinction: these are public data the server does not store, and the tool points to official sources. The long parenthetical list is useful for scope but makes the opening sentence heavy.

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 two-parameter reference tool with full schema coverage, no output schema, and annotations already declaring read-only behavior, the description is largely complete: it explains the data categories, the official sources, the optional rule, and how it relates to renta_resumen. It is slightly incomplete on freshness/versioning of the referenced rates and tables.

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%, so the schema already documents both parameters. The description adds some meaning for regla=true by specifying a step-by-step F22 estimate for a person with salary and honorarios, but it does not add information about the buscar filter beyond the schema.

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?

It clearly states a specific purpose: a guidance/reference tool that tells which official page to consult for each public tax/social-security datum and what to search there, with an optional step-by-step F22 rule. It explicitly distinguishes itself from sibling renta_resumen by assigning private data there and public data here.

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 gives explicit timing and routing: use it before estimating income, private data comes from renta_resumen, public data from the named official pages, and the year calculated determines the figures. It also states a clear exclusion: 'No va al SII.'

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond them by disclosing conditional yield ('si se sincronizaron las boletas de honorarios…') and the default scope of all months with data, but it says nothing about volume, pagination, or whether findings are empty when reconciliation is clean.

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?

One front-loaded sentence that leads with the core term and then enumerates finding types; nothing is redundant. The nested parenthetical with the conditional honorarios clause makes it dense and slightly harder to parse than it needs to be.

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?

There is no output schema, so the description carries the burden of explaining what a 'hallazgo' looks like (fields, counts, severity levels) and does not. It is adequate for deciding whether to call the tool, but thin for interpreting results or understanding the meaning of the severity filter.

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 75%, just below the high-coverage baseline, and the description only echoes the desde/hasta semantics already documented in the schema. The 'severidad' parameter has no description in the schema and is never mentioned in the description, so the meaning of info/advertencia/critico is left entirely unstated.

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?

Names the specific resource (hallazgos de conciliación de IVA) and enumerates the concrete finding types it returns — descuadres, F29 faltantes, facturas por reclamar, cambios posteriores al F29, retención de honorarios vs código 151. That is far more specific than a sibling like iva_resumen, though it never says explicitly whether it lists, computes, or returns findings, and it doesn't name the sibling contrast outright.

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 trailing phrase 'de todos los meses con datos, o de un rango' implies the default scope and when to pass a period range, which is useful usage signal. However, there is no explicit when-to-use-this-instead-of guidance versus iva_resumen or f29_historial, and no prerequisites (e.g. that the RUT must already be synchronized).

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: operations run against a local copy whose staleness must be verified, with a sync step as remedy. It stops short of describing output shape or failure behavior when F29 is missing for the period.

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?

Two tight sentences, front-loaded with the comparison and the reviewed artifacts before the local-data caveat. Slightly dense enumeration of four checks in one clause, but nothing is wasted.

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, the description should signal what comes back; 'entrega los hallazgos de un mes' plus the enumerated checks give a reasonable sense of the result. Missing is what happens when the period has no F29 or no RCV documents, which matters for a reconciliation tool.

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 rut and periodo are already documented with format and pattern. The description only implies a single month is analyzed ('de un mes') and adds no syntax, range or edge-case guidance 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 specific verbs (compara, revisa, entrega) and concrete resources (débito/crédito del RCV, F29 presentado, remanente, documentos pendientes, plazos). An agent can see this is a monthly VAT reconciliation summary, though it never explicitly contrasts itself with iva_hallazgos, which the phrase 'entrega los hallazgos' partly overlaps.

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 actionable precondition: it reads only the local base, so check 'frescura' and run the sync (sincronizar) when data is stale. It does not state when to prefer this over iva_hallazgos or renta_resumen, so the sibling routing is only partially covered.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds that results include each taxpayer's SII session state, but says nothing about behavior with no configured profiles, ordering, or whether session state can be stale.

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?

Two short sentences, front-loaded with what is returned and then the actionable usage hint. No filler or redundancy.

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 zero-param, read-only list tool with no output schema, the description covers what entities appear and one key returned field. A note on empty-configuration behavior or the RUT format would close the remaining gap.

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?

The tool takes no parameters, so there is no parameter semantics to explain; the description correctly does not invent any. Baseline 4 applies for a zero-parameter tool.

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?

Specific verb ('Lista') plus a concrete resource ('contribuyentes configurados') and the returned field ('estado de su sesión SII'). It is clear what the tool does, though it never names which sibling it differs from (e.g. sii_panorama), leaving the distinction to inference.

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?

'Úsala primero para saber qué RUT consultar' gives explicit sequencing guidance and the reason for calling it before other tools. It stops short of stating when not to use it or which specific sibling to follow with.

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

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

Goes well beyond the annotations: it discloses that SII-reported companies overwrite manually entered `representa` data, that only RUT, razón social, privileges and deauthorization date are stored, and that emails/phones/addresses are deliberately not stored. It also covers auth behavior and the read-only nature of the upstream SII call, which reconciles with readOnlyHint=false (the write happens locally) and idempotentHint=true.

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 core behavior (what is fetched and what is replaced) is front-loaded in the first sentence, and each following clause carries distinct behavioral information. It is dense and slightly run-on, with the F29 day-20/day-12 rule sitting a bit tangentially, but no sentence is wasted.

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, the description still conveys what gets persisted, what gets overwritten, and what the no-session response looks like. It does not describe the success response shape, which is the only notable gap for a sync tool of this complexity.

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?

There is only one parameter and the schema already documents it at 100% coverage with an example format (22.222.222-2). The description adds nothing about the RUT beyond what the schema provides, 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 concrete verb and resource: it pulls the tax profile from SII (F29 authorization, régimen, segmento) plus the list of companies the taxpayer may query, and replaces the `representa` field. This is far more specific than the title, but it never names its siblings (perfiles_listar, renta_sincronizar, sincronizar), leaving the agent to infer when this differs from the other sync tools.

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 ordering rule — 'sincroniza la cuenta antes de revisar plazos' — and explains the fallback path when there is no session (the response points to the «Abrir mi-sii-mcp.cmd» page, never ask for the password in chat). It does not state when to use a sibling instead, so a 4 rather than a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuine domain context — the 8-day reclaim window and the two data sources — but says nothing about return shape, ordering, or scope of the lookahead window.

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?

A single dense sentence with the resource front-loaded and no filler. It is efficient, though the parenthetical '(8 días)' is the only piece of framing an agent gets about the window semantics.

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 an undocumented 'dias' parameter, the description should at minimum describe what the response contains (a list of deadlines keyed by type) and how 'dias' bounds it. It omits both, so an agent can call it but cannot reason about its results.

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 only 50%: 'rut' is documented in the schema, but 'dias' has no description anywhere and the tool description never mentions it, leaving the lookahead window's meaning entirely undefined. The description adds no parameter-level information beyond what the schema already provides.

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?

Names the resource precisely ('Vencimientos próximos') and enumerates the two things it aggregates: F29 filings pending and received invoices nearing the 8-day claim deadline. This differentiates it from siblings like f29_historial or rcv_documentos, though it never explicitly names or contrasts those alternatives.

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 'próximos' framing implies the usage context (checking what's due soon), but there is no explicit when-to-use, when-not, or pointer to alternatives such as f29_releer for a single F29. The agent must infer the routing decision.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds useful behavior in 'paginada (50 por página)' and the one-month scoping, but says nothing about result ordering, total page counts, or what happens if pagina exceeds the range.

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?

A single dense sentence that front-loads the core action and page size, then lists filter dimensions. No filler, no repetition of the title.

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 7 parameters, 29% schema coverage and no output schema, the description is thin: it never indicates what fields a returned document contains, what tipo_doc integer codes mean, or how results are ordered across pages. For a filtered list tool with no output schema, that leaves the agent guessing at both inputs and returns.

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 only 29% (rut and periodo documented), so the description must compensate; it does partially by naming the filter dimensions lado, estado, tipo de documento and contraparte in natural language. However, tipo_doc's integer codes remain unexplained in both schema and description, and rut_contraparte's expected format is never stated.

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 resource ('Lista ... documentos del RCV') plus scope (one month, 50 per page) and the filter dimensions available. An agent can tell this is a paginated document listing rather than an aggregate or sync tool, though the description never explicitly differentiates it from siblings like iva_resumen or sincronizar.

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 mention of filters by lado, estado, tipo and contraparte implies how the tool is used to narrow results, but there is no explicit statement of when to choose this over the sibling summary/sync tools or what to do when results span multiple pages. Usage is inferable but not guided.

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

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

Beyond annotations it discloses key behavior: no consulta al SII (datos locales, por eso hay que sincronizar), que los montos vienen reajustados por IPC, la tolerancia de cuadre del 0 %–10 % entre F22 y boletas, y que en DJ 1879 se cruza la retención informada. Estos detalles operativos no están en las anotaciones y evitan interpretaciones erróneas del resultado.

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?

Content is front-loaded with what the tool returns, followed by routing advice, and every clause carries information. The single dense paragraph chains many clauses (cross-checks, DJ 1879 rules) and would read better split into sections, but nothing is truly redundant.

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, the description carries the return-value burden and does it well: enumerates the F22 fields, the boleta breakdown, top-5 pagadores, and the DJ structure with statuses and observed-declaration warning. Nothing an agent needs to decide whether this tool answers its question is missing.

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%, and the schema itself documents the rut format and the anio rule (año comercial + 1). The description reinforces 'por año tributario' but adds no syntax or default behavior beyond the schema, so 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 verb (Muestra) and resource (renta F22 guardada localmente) with the exact scope: folio, conclusión SII, impuesto, giro, remanente, códigos con glosa, observaciones, eventos, boletas de honorarios, cruces 547/492 y DJ de terceros. An agent can tell this apart from renta_sincronizar and consulta_sql without opening any schema.

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?

Explicitly routes alternative questions: «¿a quién le emití boletas?» o por mes/receptor → consulta_sql sobre bhe_emitida; sin datos → renta_sincronizar; demás códigos → f22_valor y bhe_emitida_mes. It also names where third-party data lives (dj_tercero), giving clear when-to-use vs when-not-to-use guidance.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, openWorldHint=true) the description discloses concrete traits: it reads only from the SII and stores nothing sensitive (no names, address, account, bank), preserves previously stored data when the SII returns empty, caps the range at 10 years, and explains the no-session recovery path without asking for credentials in chat.

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 range limit are front-loaded, and every clause carries operational content. It is a single dense paragraph of roughly 150 words, which is long but justified by the number of distinct data classes it retrieves.

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, the description carries the return-value burden and does so thoroughly, enumerating declarations, conclusions, folio codes with glosas, observations, events, boleta-level detail with amounts and withholdings, and DJ informants with their months, amounts and SII observations. Error/degradation behavior is also covered.

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 adds real meaning on top by clarifying the año tributario convention (commercial year + 1) and imposing a 10-year maximum span across desde/hasta, which the schema does not state.

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 names a specific verb chain (fetch F22 from SII and persist it locally) plus the exact resource set: annual declarations, boletas de honorarios, and DJ filings by third parties. It implicitly distinguishes itself from read-only siblings like renta_resumen by stressing that it writes to the local database, but it never names an alternative 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?

It gives useful context conditions (using the next tax year to see current-year boletas without an F22, max 10 years per call, session-required path), but it never says when to prefer renta_resumen or sii_panorama over a sync, nor any when-not guidance.

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

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

Annotations already cover read-only, idempotent, non-open-world, so the bar is lower; the description still adds real context by stating it never reaches the SII and only reads stored data, plus the conditional availability of propuesta F29, boletas and F22 ('si se sincronizaron'). It doesn't say what is returned when nothing is stored locally, which is the main remaining behavioral gap.

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 is front-loaded in the first clause, followed by the payload list and then the two behavioral constraints in a short second sentence. The enumeration is dense but every item is informative; only the long single sentence testing readability keeps it from a 5.

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, the description does the necessary work of enumerating what comes back (monthly amounts, RCV coverage, F29, propuesta F29, boletas, F22 by tax year, account data) and flags which parts are conditional. It could still say more about the shape/aggregation of 'montos' and the empty-state 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?

The single parameter has 100% schema coverage with a concrete example format (22.222.222-2), so the schema carries the burden. The description adds only that the RUT scopes the whole panorama; no extra syntax or normalization guidance beyond the schema.

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 verb ('Muestra') and a precisely scoped resource: an all-months local panorama for a RUT, with the exact contents enumerated (RCV compras/ventas, F29, propuesta F29, boletas, F22, datos de cuenta). It also explicitly contrasts with period-scoped and sync siblings ('No requiere un período y no descarga datos del SII'), so an agent can distinguish it without opening the schema.

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 clear usage context: this is the cross-period overview and requires no period argument, and it is strictly a local read rather than a download. It doesn't name the alternative to call when the user needs fresh SII data (e.g. sincronizar / perfil_sincronizar), leaving that inference to the reader.

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

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

Adds substantial context beyond annotations: it is strictly read-only against the SII (never submits or modifies anything there, consistent with readOnlyHint=false only because it writes to the local DB), explains what each optional surface adds (propuesta = proposed credit/remainder/withholding without debit or total payable; bhe = honorarios receipts crossed with F29 code 151), and discloses session-failure behavior and a security rule (never ask for the password in chat).

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 is front-loaded in the first sentence and every sentence carries information. It is a single dense run-on paragraph with stacked parentheticals, which makes it harder to scan than a short bulleted structure would.

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 4-parameter sync tool with no output schema, it covers scope, defaults, optional surfaces, batching strategy and failure handling. It does not describe what the response contains per surface (counts, errors, partial results), which an agent may want before calling, though the response itself reportedly explains the auth path.

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 75% schema coverage, the schema already documents rut, desde and hasta. The description adds real meaning for superficies — the four accepted values, their semantics and which are on by default — plus the effective 120-month cap on the desde/hasta range, which the schema does not express.

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?

Specific verb+resource: pulls RCV (purchases and sales) and F29 from the SII portal for a month range and stores them locally. It explicitly contrasts itself with renta_sincronizar (F22) and perfil_sincronizar (profile/authorized companies), so an agent can distinguish it from siblings without reading any schema.

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?

States default behavior (rcv and f29 by default; propuesta and bhe optional and not included by default), when to use the sibling tools instead (renta_sincronizar for F22, perfil_sincronizar for profile), and operational guidance: max 120 months per call, use 12-month batches for long history to avoid client timeouts.

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