Skip to main content
Glama
Yoryoboy

ArcaMCP

by Yoryoboy

Crear PDF de factura

create_pdf

Generates a dynamic PDF for an AFIP electronic voucher by combining voucher, issuer, and receiver data, helping you review and confirm the invoice before proceeding.

Instructions

Genera un PDF dinámico de un comprobante electrónico combinando datos del voucher, emisor y receptor desde AFIP. La manera más recomendada de llenar la información para la factura de manera correcta es utilizar las herramientas apropiadas para recuperar los datos del CAE y los datos tanto del emisor como del receptor utilizando sus CUIT. El LLM no debe asumir ninguna información que no haya sido dada explícitamente o que no pueda inferir. Una vez todos los datos estén recopilados, se debe hacer un resumen de la factura tal cual como quedaría y mostrársela al usuario antes de proceder. Procederemos solo cuando tengamos la confirmación explícita del usuario. Si A13 devuelve varios domicilios elegibles de igual prioridad, reintentar con DIRECCION_EMISOR_SELECCIONADA usando uno de los candidatos devueltos. Este campo se valida contra A13 y no permite direcciones arbitrarias. Nota importante: este tool usa dos campos relacionados al tipo de comprobante para evitar ambigüedad: CbteTipo (código numérico AFIP para uso técnico/QR) y CbteLetra (A/B/C/M) únicamente para la visualización en el PDF.

Input Schema

NameRequiredDescriptionDefault
MonIdNoCódigo de moneda (ej: PES)PES
DocNroNoNúmero de documento del receptor (CUIL/CUIT). Debe ser de 11 dígitos, sin puntos ni guiones. Si no corresponde declarar receptor, dejar explícitamente en blanco (string vacío). Este schema normaliza 0 o cadenas de solo ceros ('000...') a vacío. No inventar números. Si el usuario no lo ha especificado y es necesario, preguntar: el LLM no debe asumir esta información.
PtoVtaYesPunto de venta del comprobante. Se le debe agregar '0000' al inicio. Por ejemplo, si es 2, se pone '00002'
CbteFchYesFecha del comprobante
CbteNroYesNúmero del comprobante
CbteTipoYesCódigo numérico del tipo de comprobante según AFIP (por ejemplo, Factura C = 11). Este valor se utiliza para propósitos técnicos como la generación del QR y debe obtenerse con el tool get_voucher_types. IMPORTANTE: Para la letra que se muestra en el PDF (A/B/C/M), usar el campo CbteLetra.
ConceptoYesConcepto del comprobante: 1=Productos, 2=Servicios, 3=Productos y Servicios
MonCotizNoCotización moneda
SUBTOTALYesSubtotal de la factura
CbteLetraYesLetra del comprobante para visualización en el PDF (A/B/C/M). No utilizar aquí el Id numérico devuelto por get_voucher_types. Si sólo se dispone de la descripción (p. ej., 'Factura C'), extraer la letra (C). Se define CbteLetra separado de CbteTipo para evitar ambigüedad: CbteTipo es el código numérico para AFIP/QR, mientras que CbteLetra es únicamente la representación visual en el PDF.
CAE_NUMBERYesNúmero de autorización del comprobante
FchVtoPagoNoFecha de vencimiento de pago. En caso de no ser necesario declarar el servicio, se puede omitir. Dejar espacio en blanco. Lo ideal sería obtener la información del CAE al que se le está generando esta factura para obtener los datos de las fechas de inicio, fin y pago del servicio.
TipoCodAutNoTipo de autorización del comprobante para QR: 'E' (CAE) o 'A' (CAEA)E
FchServDesdeNoFecha de inicio de servicio. En caso de no ser necesario declarar el servicio, se puede omitir. Dejar espacio en blanco. Lo ideal sería obtener la información del CAE al que se le está generando esta factura para obtener los datos de las fechas de inicio, fin y pago del servicio.
FchServHastaNoFecha de fin de servicio. En caso de no ser necesario declarar el servicio, se puede omitir. Dejar espacio en blanco. Lo ideal sería obtener la información del CAE al que se le está generando esta factura para obtener los datos de las fechas de inicio, fin y pago del servicio.
IMPORTE_TOTALYesImporte total de la factura
INVOICE_ITEMSNoÍtems de factura
CONDICION_PAGONoCondición de venta / medio de pago. Seleccionar una opción del enum: Contado, Efectivo, Transferencia, Depósito, Tarjeta de Débito, Tarjeta de Crédito, Mercado Pago, Billetera virtual, Cheque, Cuenta Corriente, A crédito, Contraentrega, QR interoperable u Otros. Si el usuario no lo ha especificado, preguntarle y no asumir esta información.Contado
CAE_EXPIRY_DATEYesFecha de vencimiento de la autorización
INGRESOS_BRUTOSYesCondición obligatoria de Ingresos Brutos; Local y Convenio Multilateral requieren inscripción.
NOMBRE_RECEPTORYesNombre del receptor. En caso de no ser necesario declarar el receptor, se puede omitir. Dejar espacio en blanco
CondicionIVAEmisorYesCondición frente al IVA del emisor. Si el usuario no lo ha especificado, se deberá encontrar las opciones disponibles utilizando el tool get_tax_condition_types y se le deberá preguntar al usuario. Esta información nunca debe ser asumida, tiene que ser confirmada por el usuario.
DIRECCION_RECEPTORNoDirección del receptor. En caso de no ser necesario declarar el receptor, se puede omitir. Dejar espacio en blanco. Si es necesario declarar el receptor, se puede encontrar la informacion del receptor usando el tool get_taxpayer_details
CondicionIVAReceptorYesEn caso de ser consumidor final, simplemente poner 'Consumidor Final'
IMPORTE_OTROS_TRIBUTOSNoImporte de otros tributos
FECHA_INICIO_ACTIVIDADESYesFecha legal de inicio de actividades en formato YYYY-MM-DD
DIRECCION_EMISOR_SELECCIONADANoDomicilio del emisor seleccionado explícitamente de los candidatos actuales de A13. Solo se acepta si coincide con un domicilio elegible y normalizado devuelto por AFIP; no usar para proporcionar una dirección arbitraria.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare this is non-read-only, open-world, non-idempotent, and non-destructive. The description adds useful behavioral context: user confirmation is required before generation, data must not be assumed, and DIRECCION_EMISOR_SELECCIONADA is validated against A13 rather than accepting arbitrary values.

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 front-loaded with purpose and then moves into workflow rules, which is appropriate for a complex 27-parameter tool. It is somewhat verbose and repeats some 'do not assume' guidance already covered in the schema, but most sentences earn their place given the workflow complexity.

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?

The description covers the generation workflow, confirmation requirement, and A13 address validation, which is substantial for a complex create operation. However, with no output schema, it does not explain what the PDF generation returns, such as a file path, URL, or inline binary, leaving an important gap for invocation.

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 description coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema. It explicitly clarifies the distinction between CbteTipo as the AFIP/QR numeric code and CbteLetra as the PDF display letter, and explains that DIRECCION_EMISOR_SELECCIONADA must match an A13-returned eligible address.

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?

The description states a specific verb and resource: 'Genera un PDF dinámico de un comprobante electrónico' and explains that it combines voucher, emisor, and receptor data from AFIP. This clearly distinguishes it from sibling tools that create or retrieve vouchers rather than render a PDF.

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?

It gives clear workflow guidance: gather data with the appropriate tools, do not assume missing information, summarize the invoice for the user, and proceed only after explicit confirmation. It also gives a specific retry path for A13 multiple-address cases, though it does not name create_voucher or another exact sibling as the prerequisite alternative.

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