Argentina Invoices (factura electrónica CAE via WSFE)
Server Details
Argentina AFIP/ARCA electronic invoices for AI agents - issue & query facturas, get CAE via WSFE.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: creating an invoice, retrieving the last invoice number for planning, and querying an existing invoice. There is no overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (create_invoice, get_last_invoice_number, query_invoice), making them predictable and easy to differentiate.
Three tools are well-scoped for the server's purpose: issuing electronic invoices, retrieving the next invoice number, and querying past invoices. The count is appropriate without being excessive or insufficient.
The tool set covers the key invoice lifecycle tasks (preparation via last number, creation, and retrieval). Update or deletion are not typical in this context, so only a minor gap like listing all invoices might exist, but it's reasonable given the focus on individual invoice operations.
Available Tools
3 toolscreate_invoiceAInspect
Issue an Argentina AFIP/ARCA electronic invoice (factura electrónica) and get the CAE (Código de Autorización Electrónico) via WSFE, through the Afip SDK. Bring your own Afip SDK access_token via header x-afipsdk-token (sign up free at app.afipsdk.com — 1000 requests/month). Header x-afip-mode: dev (default, no AFIP certificate needed — test CUIT 20409378472) or prod. Header x-afip-cuit: the 11-digit issuer CUIT (defaults to the test CUIT in dev). In prod, pass your AFIP X.509 certificate + private key per-request as afip_cert / afip_key (PEM strings) — they are forwarded to Afip SDK for this request only and never stored or logged. Give flat fields (invoice_type, point_of_sale, customer doc, line items with net_price + iva_rate) and this server COMPUTES the WSFE amounts: ImpNeto, ImpIVA (grouped AlicIva array), ImpTotal — IVA is discriminated for Factura A/B and not discriminated for Factura C (monotributo). The next invoice number is fetched automatically (FECompUltimoAutorizado) unless you pass invoice_number. Returns cae, cae_expiry and invoice_number.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Line items. Each: description, net_price (unit price in ARS, tax-EXCLUSIVE), optional quantity (default 1) and iva_rate (VAT percent: 0, 10.5, 21, 27; default 21; IGNORED for Factura C which does not discriminate IVA). | |
| concept | No | Concepto: PRODUCTS (default), SERVICES, or BOTH. | |
| afip_key | No | Optional AFIP private key (PEM) for prod mode. Forwarded per-request to Afip SDK, never stored or logged. Not needed in dev. | |
| currency | No | Currency code (MonId). Default PES (Argentine peso). Use with foreign currency only if your AFIP setup allows it. | |
| afip_cert | No | Optional AFIP X.509 certificate (PEM) for prod mode. Forwarded per-request to Afip SDK, never stored or logged. Not needed in dev. | |
| invoice_type | No | Factura type: C (default, monotributo — IVA not discriminated, CbteTipo 11), B (final consumer, CbteTipo 6), A (registered VAT buyer, CbteTipo 1). A/B discriminate IVA per line. | |
| point_of_sale | No | Punto de venta (PtoVta) registered at AFIP for electronic invoicing. Default 1. | |
| invoice_number | No | Optional explicit invoice number (CbteDesde/Hasta). If omitted, the server queries FECompUltimoAutorizado and uses last+1. | |
| customer_doc_type | No | Buyer document type: CUIT (80), DNI (96), or CF = Consumidor Final unidentified (99, doc number 0). Default CF for Factura B/C, CUIT for Factura A. | |
| customer_doc_number | No | Buyer document number (digits only). For CF use 0 or omit. Required (non-zero) for Factura A. | |
| customer_iva_condition | No | CondicionIVAReceptorId (AFIP RG 5616): 1 IVA Responsable Inscripto, 4 Exento, 5 Consumidor Final (default), 6 Responsable Monotributo. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool computes WSFE amounts, auto-fetches invoice numbers unless overridden, and that credentials are per-request and not stored. This adds significant behavioral context beyond annotations.
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 detailed but somewhat verbose, repeating header instructions. It front-loads the main purpose but could be more concise.
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 complex tool with 11 parameters and no output schema, the description covers dev/prod modes, header usage, computation logic, and automatic numbering. Missing error handling details, but overall complete.
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 baseline is 3. The description adds overall flow context but does not significantly enhance individual parameter meanings 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?
The description uses the specific verb 'Issue' and clearly identifies the resource: an Argentina AFIP/ARCA electronic invoice with CAE. It distinguishes from sibling tools 'get_last_invoice_number' and 'query_invoice' by its creation action.
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 explains when to use (to issue invoices) and provides context on dev vs prod, headers, and prerequisites. It implicitly contrasts with siblings but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_last_invoice_numberARead-onlyInspect
Get the last authorized invoice number (FECompUltimoAutorizado via WSFE) for a given point of sale and invoice type — the next invoice is this number + 1. Useful to compute the next number before issuing, or to reconcile. Returns last_number and next_number.
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_type | No | Factura type A/B/C. Default C. | |
| point_of_sale | No | Punto de venta (PtoVta). Default 1. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that it returns last_number and next_number, but does not mention authentication, rate limits, or behavior when no prior invoice exists. It does not contradict annotations.
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 with no redundancy. The core purpose is in the first sentence, followed by usage guidance and output fields. Every sentence earns its place.
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 simple read tool with 2 parameters and no output schema, the description is fairly complete. It explains the return value (last_number and next_number) and the computation (+1). A minor gap: it doesn't specify the exact JSON structure, but that is acceptable given the tool's simplicity.
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 baseline is 3. The description adds value by explicitly stating default values (Default C, Default 1) and the relationship 'next invoice is this number + 1', which goes beyond the schema descriptions.
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 clearly states the verb 'Get', the resource 'last authorized invoice number', and the specific context via WSFE. It distinguishes this tool from siblings (create_invoice, query_invoice) by focusing on a narrow, specific retrieval operation.
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 explicitly mentions use cases: 'compute the next number before issuing, or to reconcile.' It implies when not to use (e.g., not for creating or querying all invoices), but does not explicitly contrast with siblings. However, the purpose is clear enough for an agent to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_invoiceARead-onlyInspect
Look up an issued Argentina electronic invoice at AFIP/ARCA by its number (FECompConsultar via WSFE). Give invoice_number, point_of_sale and invoice_type; returns the CAE, cae_expiry, total and Resultado (A = authorized/approved, R = rejected/authorized). Safe to call anytime.
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_type | No | Factura type A/B/C (must match how it was issued). Default C. | |
| point_of_sale | No | Punto de venta (PtoVta). Default 1. | |
| invoice_number | Yes | The invoice number (CbteNro) returned by create_invoice. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true and openWorldHint=true. The description adds that the tool returns CAE, cae_expiry, total, and Resultado, and emphasizes safety. No contradiction with annotations.
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 sentence, front-loaded with the main action and includes both purpose and return fields. It is efficient but slightly dense, with no wasted words.
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 read-only query tool with 3 parameters and no output schema, the description covers the core functionality and key return fields. It lacks error handling or missing invoice scenarios, but is mostly complete given annotations.
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% with descriptions for all parameters. The description repeats the parameter names and adds default values (invoice_type default C, point_of_sale default 1) already present in the schema. The added value is minimal, so baseline 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?
Description clearly states the verb 'look up', the resource 'Argentina electronic invoice at AFIP/ARCA', and the method (FECompConsultar via WSFE). It distinguishes from siblings create_invoice and get_last_invoice_number by focusing on querying an existing invoice.
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 tells the agent to provide invoice_number, point_of_sale, and invoice_type, and notes the tool is 'Safe to call anytime.' However, it does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!