Skip to main content
Glama
Taksuma-0

mi-sii-mcp

by Taksuma-0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Resumen de la renta (F22)

renta_resumen
Read-onlyIdempotent

Displays a locally saved F22 income tax summary by tax year, including paid tax, SII codes and observations, honoraria receipts, third-party reports, and reconciliation mismatches.

Instructions

Muestra la renta (F22) guardada localmente por año tributario: folio vigente, conclusión del SII, impuesto pagado, giro y remanente, los códigos del resultado con su glosa del SII, observaciones y eventos. De una persona muestra además sus boletas de honorarios emitidas del año comercial (vigentes, anuladas, bruto y retención) y su cruce con los códigos 547 (ingresos brutos) y 492 (retención) del F22, que vienen reajustados por IPC: cuadra si el F22 trae entre 0 % y 10 % más; con el detalle boleta por boleta, también sus 5 principales pagadores. También muestra lo informado por terceros (DJ): cada informante con sus meses, monto y estado, con un aviso si su declaración está observada por el SII; en la DJ 1879 cruza la retención informada con las boletas emitidas a ese RUT y la total con las boletas del año y con el 492 del F22 (cuadra o difiere por cuánto). Para preguntas como «¿a quién le emití boletas?» o por mes y receptor, usa consulta_sql sobre bhe_emitida. Lo informado por terceros está en dj_tercero. No va al SII: si no hay datos, usa renta_sincronizar. Los demás códigos están en f22_valor y las boletas por mes en bhe_emitida_mes (consulta_sql).

Input Schema

NameRequiredDescriptionDefault
rutYesRUT del contribuyente, por ejemplo 22.222.222-2
anioNoAño tributario AAAA (año comercial + 1): 2026 es la renta del año 2025

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server

Other Tools