Skip to main content
Glama
Yoryoboy

ArcaMCP

by Yoryoboy

Crear próximo comprobante electrónico

create_next_voucher
Destructive

Create the next AFIP electronic voucher with automatic numbering and assigned CAE, validating invoice data and confirming details before issuance.

Instructions

Crear el próximo comprobante electrónico en AFIP con numeración automática y CAE asignado.

Instrucciones para el asistente: Antes de ejecutar esta herramienta, entiende y valida exhaustivamente todos los parámetros requeridos según el tipo de comprobante a emitir (concepto, tipo de factura, moneda, punto de venta, importes, fechas, ítems, etc.). Si falta información o hay inconsistencias, solicita explícitamente los datos faltantes al usuario.

Recomendación clave: previo a usar esta herramienta, consulta los puntos de venta disponibles del usuario y asegúrate de recibir el número de punto de venta correcto (PtoVta).

Flujo sugerido: 1) Validar parámetros y completar faltantes preguntando al usuario. 2) Sugerir y/o consultar puntos de venta disponibles si no se proporcionó PtoVta. 3) Preparar y presentar un resumen claro y completo de la factura que se generará (todos los campos relevantes, importes y fechas). 4) Solicitar confirmación explícita del usuario. 5) Recién entonces proceder a crear el comprobante.

Atención: Mantente atento a cualquier notificación, instrucción adicional o preferencia que el usuario indique durante el proceso y ajústalo antes de ejecutar la herramienta.

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
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
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
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

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true; the description adds the human-in-the-loop confirmation requirement and the fact that AFIP assigns numbering and a CAE, which is meaningful context beyond the flags. It never states plainly that each invocation consumes the next sequential number and cannot be undone or retried safely — the single most important behavior for a non-idempotent fiscal write.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded correctly, but the body repeats itself: validation-before-execution is stated in the opening instruction, again as flow step 1, and again in the closing "Atención" paragraph. The "Recomendación clave" about PtoVta duplicates flow step 2 and is also already in the PtoVta schema description. Tightening to purpose + flow + confirmation gate would lose nothing.

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

Completeness3/5

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

For a 22-parameter, 14-required, destructive issuance tool with no output schema, the description covers the pre-flight workflow and prerequisite lookups well. It is silent on what the agent receives on success (CAE, voucher number, expiry), on error/failure behavior when AFIP rejects the request, and on how this differs from create_voucher — gaps an agent must resolve before calling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so per-field semantics are already documented, which sets the baseline at 3. The description goes beyond that by enumerating the parameter categories that must be validated (concepto, tipo de factura, moneda, punto de venta, importes, fechas, ítems) and mandating that missing data be requested from the user rather than assumed — a cross-cutting constraint the schema does not express.

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+resource ("Crear el próximo comprobante electrónico en AFIP") plus two distinguishing traits: automatic numbering and CAE assignment, which tell the agent this is a real fiscal issuance, not a draft. However, the sibling list contains create_voucher and the description never explains how this tool differs from it, so the agent cannot disambiguate between the two write paths.

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

Usage Guidelines4/5

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

Provides an explicit 5-step pre-execution flow (validate params, resolve PtoVta, present a summary, get explicit confirmation, then create) and a hard gate on user confirmation — far above typical guidance. It stops short of naming alternatives (create_voucher) or stating when NOT to use this tool, so it does not reach 5.

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