Paraguay Invoices (SIFEN e-Kuatia via FacturaSend)
Server Details
Paraguay SIFEN e-Kuatia: AI agents issue and query electronic invoices, stateless BYO.
- 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.4/5 across 3 of 3 tools scored.
Each tool serves a distinct purpose: create_invoice issues new invoices, get_document_status checks live SIFEN approval status, and query_invoice retrieves stored metadata. No functional overlap, clear differentiation.
All tool names follow a consistent verb_noun pattern in snake_case: create_invoice, get_document_status, query_invoice. Convention is uniform and predictable.
Three tools cover the core lifecycle of invoice creation, status checking, and metadata lookup. The count is slightly minimal but well-scoped for a focused integration; additional tools like cancellation or listing could enhance completeness.
Essential operations are present (create, status, query), but notable gaps exist: there is no tool to cancel/void an invoice or to list invoices. The draft feature mitigates testing needs, but the surface is incomplete for full lifecycle management.
Available Tools
3 toolscreate_invoiceAInspect
Issue a Paraguay electronic invoice (factura electrónica, Documento Electrónico for SIFEN / e-Kuatia) through FacturaSend, which generates, digitally signs and transmits it to the DNIT (tax authority) from YOUR OWN FacturaSend account — this server only forwards the call and never holds your certificate. It wraps POST /{tenant}/lote/create with a single DE. Amounts are in Paraguayan guaraníes (PYG), which have NO decimals — pass unit prices as INTEGERS, and prices are TAX-INCLUSIVE (IVA incluido). IVA (VAT) rate per line: 10 (standard), 5 (reduced), or 0 (exempt); the server liquidates the IVA portion locally (10% -> price10/110, 5% -> price5/105). Set draft=true to build the DE WITHOUT transmitting it to SIFEN (offline test, no fiscal effect). On success you get the 44-digit cdc, the numero (establecimiento-punto-numero), and the SIFEN estado (Aprobado / Aprobado con observacion / Rechazado). Required credential headers (set once in your MCP client, per-request, never stored): x-facturasend-tenant (your FacturaSend tenant/company id, in the URL path) + x-facturasend-key (your FacturaSend API key; the free test environments never reach SIFEN production). Optional owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools.
| Name | Required | Description | Default |
|---|---|---|---|
| draft | No | true = build the DE WITHOUT transmitting to SIFEN (offline test, no fiscal effect). Default false. | |
| fecha | No | Issue date-time (ISO 8601, e.g. 2026-07-10T10:30:00). Default: now. | |
| items | Yes | Line items. Each: { descripcion, cantidad, precioUnitario (PYG integer, tax-inclusive), iva? (10|5|0, default 10), codigo?, unidadMedida? (default 77=Unidad) }. | |
| punto | Yes | Expedition point (punto de expedición), e.g. "001". | |
| moneda | No | ISO currency code. Default PYG (guaraní, 0 decimals). | |
| numero | Yes | Sequential document number for this establecimiento/punto, e.g. 123. | |
| cliente | Yes | Buyer / receptor. For a registered taxpayer set contribuyente=true and provide ruc; for a final consumer set contribuyente=false and (optionally) documentoTipo+documentoNumero. | |
| establecimiento | Yes | Establishment code of the issuing point, e.g. 1 (matches your FacturaSend timbrado config). | |
| tipoTransaccion | No | SIFEN transaction type 1-13. Default 1 (venta de mercadería / sale of goods). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond annotations: it explains the server only forwards calls without holding certificates, wraps a specific API endpoint, and details the output (cdc, numero, estado). Annotations indicate a write operation (readOnlyHint=false) and idempotentHint=false, which the description reinforces. No contradiction.
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 and front-loaded with the core purpose, but it is somewhat lengthy. It could be streamlined by separating credential header instructions, but overall structure is logical.
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?
Given the tool's complexity (nested objects, no output schema), the description provides complete contextual information: return values, credential headers, draft mode, and parameter behavior. No gaps remain.
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?
While schema coverage is 100%, the description adds interpretive value: e.g., precioUnitario must be integer and tax-inclusive, IVA rates are explained with examples, and currency is PYG. This enhances understanding beyond the schema alone.
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 identifies the tool as creating a Paraguay electronic invoice via FacturaSend, specifying the generation, digital signing, and transmission to DNIT. This distinguishes it from sibling tools like get_document_status (read) and query_invoice (query).
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 provides comprehensive usage context, including when to use (issuing Paraguay SIFEN e-invoices), key constraints (PYG integer, tax-inclusive, IVA rates), and draft mode for testing. However, it does not explicitly contrast with siblings or 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_document_statusARead-onlyIdempotentInspect
Consult the live SIFEN status of a Paraguay DE by its cdc — wraps POST /{tenant}/de/estado. FacturaSend queries DNIT/SIFEN and returns the estado: "Aprobado" (approved, fiscally valid), "Aprobado con observacion" (approved with an observation), or "Rechazado" (rejected — read respuesta_mensaje, fix, and re-issue). Also returns situacion, fecha, respuesta_codigo and respuesta_mensaje (the SIFEN message, e.g. "0260 Autorización del DE satisfactoria"). Required credential headers (set once in your MCP client, per-request, never stored): x-facturasend-tenant (your FacturaSend tenant/company id, in the URL path) + x-facturasend-key (your FacturaSend API key; the free test environments never reach SIFEN production). Optional owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools.
| Name | Required | Description | Default |
|---|---|---|---|
| cdc | Yes | The 44-digit cdc (control code) of the document to consult in SIFEN. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; the description adds valuable context about the underlying POST endpoint, response fields (estado, situacion, etc.), and credential requirements, going beyond structured data.
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 front-loaded with the core purpose and response details; however, the extensive header notes could be streamlined. Overall, it is well-organized and informative.
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?
Given the single parameter, no output schema, and good annotations, the description fully explains the tool's behavior, response fields, and prerequisites, leaving no significant gaps for an agent.
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?
With 100% schema coverage for the single parameter 'cdc', the description reiterates its purpose (44-digit control code) but does not add new semantics 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 clearly states the verb 'Consult' and the resource 'SIFEN status of a Paraguay DE by its cdc', and distinguishes itself from sibling tools (create_invoice, query_invoice) by focusing on status checking.
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 the returned statuses and what to do on rejection, plus credential header setup. It does not explicitly contrast with siblings, but the context implies when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_invoiceARead-onlyIdempotentInspect
Look up a previously-created Paraguay DE by its cdc (the 44-digit control code) OR by its FacturaSend internal id — pass exactly one of { cdc } or { id }. Wraps GET /{tenant}/de/cdc/{cdc} or GET /{tenant}/de/id/{id}. Returns the document metadata FacturaSend holds: id, cdc, fecha, situacion (SIFEN situation code), lote_id, lote_estado, and info_codigo/info_descripcion (e.g. "CDC duplicado"). To get the live SIFEN approval status use get_document_status instead. Safe to call anytime. Required credential headers (set once in your MCP client, per-request, never stored): x-facturasend-tenant (your FacturaSend tenant/company id, in the URL path) + x-facturasend-key (your FacturaSend API key; the free test environments never reach SIFEN production). Optional owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | The FacturaSend internal document id (alternative to cdc). | |
| cdc | No | The 44-digit cdc (control code) returned by create_invoice. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds that it wraps GET endpoints, returns specific metadata fields, and is safe to call anytime.
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?
Efficiently structured, every sentence adds value. Front-loaded purpose, then details on parameters, return fields, alternatives, and security headers.
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?
Comprehensive for tool with 2 params, no output schema, and 2 siblings. Covers usage, return fields, related tools, and required headers.
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 3. Description adds that exactly one of cdc or id must be passed and explains what each parameter represents.
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?
Clearly states it looks up a previously-created Paraguay DE by cdc or FacturaSend internal id, differentiating from sibling get_document_status.
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?
Specifies to pass exactly one of two parameters and points to get_document_status for live status. Does not explicitly state when not to use, but implications are clear.
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!