Skip to main content
Glama
Yoryoboy

ArcaMCP

by Yoryoboy

Crear comprobante electrónico

create_voucher
Destructive

Generates an AFIP electronic invoice voucher and obtains its assigned CAE for Argentine tax reporting.

Instructions

Crear un comprobante electrónico en AFIP con CAE asignado

Input Schema

NameRequiredDescriptionDefault
IvaNoAlícuotas e importes de IVA asociados. Para comprobantes tipo C y Bienes Usados – Monotributista no debe informarse
MonIdYesCódigo de moneda (ej: PES). Consultar método FEParamGetTiposMonedas
DocNroNoNúmero de identificación del comprador. Si el monto (ImpTotal) es por menos de $10.000.000 ARS y es para consumidor Final, no es necesario declarar los datos del receptor del comprobante. (DocNro puede ser omitido)
ImpIVAYesSuma de importes de IVA. Para comprobantes tipo C debe ser = 0. Para Bienes Usados – Monotributista: no debe informarse o debe ser = 0
PtoVtaYesPunto de venta del comprobante. Si se informan varios, deben corresponder al mismo punto de venta. Para obtener puntos de venta disponibles, usar tool get_sales_points. Si el usuario no especifica, se tiene que obtener sus puntos de venta disponibles y pedirle que elija uno
CantRegYesCantidad de registros del detalle del comprobante o lote de comprobantes de ingreso
CbteFchYesFecha del comprobante (yyyyMMdd). Para concepto=1: hasta 5 días anteriores/posteriores. Para 2 o 3: hasta 10 días. Si el usuario no especifica, usar la fecha actual
DocTipoYesCódigo de documento del comprador. Ej: 80=CUIT, 96=DNI, 99=Consumidor Final. Se puede recuperar todos los tipos de documentos disponibles usando tool get_document_types
ImpNetoYesImporte neto gravado. ≤ ImpTotal y ≥ 0. Para comprobantes tipo C corresponde al Subtotal. Para Bienes Usados – Monotributista: no debe informarse o debe ser = 0
ImpOpExYesImporte exento. ≤ ImpTotal y ≥ 0. Para comprobantes tipo C debe ser = 0. Para Bienes Usados – Monotributista: no debe informarse o debe ser = 0
ImpTribYesSuma de los importes de tributos
CbteTipoYesTipo de comprobante informado. Si se informa más de uno, todos deben ser del mismo tipo. Para obtener tipos de comprobante disponibles, usar tool get_voucher_types. Si el usuario no ha especificado el tipo de Factura, se tiene que obtener sus tipos de comprobante disponibles y recomendarle elegir uno.
ConceptoYesConcepto del comprobante. Valores permitidos: 1=Productos, 2=Servicios, 3=Productos y Servicios
ImpTotalYesImporte total del comprobante. Fórmula: Importe no gravado + Importe exento + Importe neto gravado + IVA + tributos. Si el monto es por menos de $10.000.000 ARS y es para consumidor Final, no es necesario declarar los datos del receptor del comprobante. (DocNro puede ser omitido)
MonCotizYesCotización de la moneda. Para PES debe ser 1
TributosNoTributos asociados al comprobante
CbteDesdeYesNro. de comprobante desde. Rango 1 – 99999999
CbteHastaYesNro. de comprobante hasta. Rango 1 – 99999999
CbtesAsocNoComprobantes asociados
FchVtoPagoNoFecha de vencimiento de pago (yyyyMMdd). Obligatorio si concepto=2 o 3. Debe ser igual o posterior a la fecha del comprobante. Si el usuario no especifica, se le debe preguntar por esta información. El LLM no debe asumir esa información
ImpTotConcYesImporte neto no gravado. ≤ ImpTotal y ≥ 0. Para comprobantes tipo C debe ser = 0. Para Bienes Usados – Emisor Monotributista, corresponde al subtotal
OpcionalesNoCampos auxiliares reservados para usos futuros
FchServDesdeNoFecha inicio servicio (yyyyMMdd). Obligatorio si concepto=2 o 3. Si el usuario no especifica, se le debe preguntar por esta información. El LLM no debe asumir esa información
FchServHastaNoFecha fin servicio (yyyyMMdd). Obligatorio si concepto=2 o 3. No menor a FchServDesde. Si el usuario no especifica, se le debe preguntar por esta información. El LLM no debe asumir esa información
fullResponseNoSi es true, devuelve la respuesta completa del WS. Si es false o no se especifica, devuelve solo CAE y CAEFchVto
CondicionIVAReceptorIdYesCondición de IVA del receptor. Si el usuario no especifica, se tienen que obtener las condiciones frente al IVA disponibles y pedirle que elija una. Para obtener las condiciones frente al IVA disponibles, usar tool get_tax_condition_types. El LLM no debe asumir esa información

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false; the description only adds that a CAE is assigned. It does not warn that this issues a real fiscal document, is non-idempotent, or describe side effects. There is no contradiction, but added behavioral context is minimal.

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?

The description is a single front-loaded sentence with no repetition. It is structurally clean, though unusually terse for a complex destructive operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 26-parameter destructive issuance tool with 17 required fields and no output schema, the description omits prerequisites, side effects, return behavior, and sibling routing. The schema carries field-level details, but the description is not complete enough for this complexity.

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 description coverage is 100% with detailed per-field descriptions, formulas, defaults, and sibling-tool references. The description itself adds no parameter meaning beyond what the schema already provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Crear un comprobante electrónico en AFIP', plus the outcome 'con CAE asignado'. It is clear what the tool does, but it does not distinguish it from the sibling create_next_voucher.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus create_next_voucher or other siblings. Prerequisites and conditions for issuance are left to the schema and agent inference.

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