Uruguay Invoices (DGI e-Factura CFE, merchant-signed SOAP relay)
Server Details
Uruguay DGI e-Factura (CFE): AI agents submit signed sobres to DGI e-invoicing, stateless forwarder.
- 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.7/5 across 6 of 6 tools scored.
Each tool has a distinct purpose: building unsigned envelopes, tax calculation, reference info, querying status, and submitting two different document types (sobre and reporte diario). No overlapping functionality.
All tool names follow a clear verb_noun pattern with underscores (build_cfe_envelope, calc_iva, get_dgi_info, query_envio_status, submit_reporte_diario, submit_sobre). Consistent and descriptive.
Six tools is well-scoped for a DGI SOAP relay server: it covers envelope building, tax calculation, reference info, querying, and two submission types. Not excessive nor insufficient.
Core workflow (build envelope, calculate taxes, submit, query) is covered. Lacks a tool for parsing DGI responses or for signing (intentionally external), but these are minor gaps given the server's relay focus.
Available Tools
6 toolsbuild_cfe_envelopeARead-onlyIdempotentInspect
Helper (pure-local, NO network, NO signing): given your signed inner DGI XML document, returns the exact SOAP 1.1 envelope Body you must WS-Security-sign before submitting. This makes the DGI Datain/xmlData structure explicit so you sign the right bytes. operation = sobre (EFACRECEPCIONSOBRE, default) | reporte (EFACRECEPCIONREPORTE) | consulta (EFACCONSULTARESTADOENVIO). Returns the envelope XML plus its base64 (unsigned — you still must add the WS-Security X.509 signature over the Body, then base64 the SIGNED envelope for submit_sobre/submit_reporte_diario/query_envio_status). Nothing is sent anywhere.
| Name | Required | Description | Default |
|---|---|---|---|
| inner_xml | Yes | Your signed inner DGI XML document (the Sobre / Reporte Diario / consulta request). Provided as raw XML (this tool escapes it into <xmlData>). It should already carry its own CFE/Sobre digital signature. | |
| operation | No | Which DGI operation to wrap for. Default sobre. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns perfectly with annotations (readOnly, idempotent, non-destructive) and adds details like 'pure-local' and 'no network', ensuring the agent understands side effects.
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 dense and front-loaded, but slightly long. Each sentence adds value, though some restructuring could improve readability.
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 no output schema, the description explains it returns envelope XML and base64. It covers key steps, but could detail the output format more precisely.
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, the description adds context: it explains inner_xml is escaped into <xmlData> and operation defaults. This enriches the schema definitions.
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 it is a local helper that builds a SOAP envelope body from a signed inner DGI XML document, distinguishing it from submission tools like submit_sobre. The purpose is specific and unambiguous.
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 says to use this before submitting, outlines the three operations, and emphasizes that no network or signing occurs. It provides clear workflow guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calc_ivaARead-onlyIdempotentInspect
Compute Uruguay IVA and CFE MontosTotales from line items (pure-local, NO network). Uruguay IVA: Tasa Básica 22%, Tasa Mínima 10%, Exento 0%. Give items with net_price (tax-EXCLUSIVE unit price), optional quantity, and either iva_rate (22 | 10 | 0) or indfact (3 | 2 | 1). Returns the CFE MontosTotales fields: MntNetoIvaTasaBasica / MntNetoIvaTasaMin / MntExento, IVATasaBasica=22 / IVATasaMin=10, MntIVATasaBasica / MntIVATasaMin, and MntTotal — ready to place in the CFE before you sign it. Amounts in UYU (or set moneda).
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Line items. Each: net_price (tax-exclusive unit price), optional quantity (default 1) and iva_rate (22 Tasa Básica default, 10 Tasa Mínima, 0 Exento) OR indfact (3/2/1). | |
| moneda | No | ISO currency code (Moneda). Default UYU. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant context beyond annotations: explains it's local, no network, details calculation (rates, fields), and currency. Aligns with annotations (readOnlyHint, idempotentHint). No contradictions.
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?
Single paragraph, front-loaded purpose, all information relevant. Slightly long but no redundancy; could be broken into bullet points for clarity.
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?
Despite no output schema, description comprehensively lists all returned fields and currency specification, making it fully self-contained for a computation tool.
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%, but description adds value by explaining defaults (iva_rate default 22, quantity default 1) and mapping between iva_rate and indfact, going beyond 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?
Description clearly states 'Compute Uruguay IVA and CFE MontosTotales from line items', specifying tax rates and output fields. Distinguishes from siblings like build_cfe_envelope which are about envelope construction, not computation.
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?
Implies usage before building CFE envelope ('ready to place in the CFE before you sign it') and states 'pure-local, NO network', but lacks explicit when-not or alternative tools guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dgi_infoARead-onlyIdempotentInspect
Reference (pure-local, NO network): the DGI e-Factura webservice endpoints, the three SOAP operations and their SOAPActions, the CFE document-type codes (TipoCFE), and the IVA rates/namespaces — so an agent can orient before signing. The test (ePrueba) endpoint is verified live; produccion must be confirmed against your DGI onboarding. No credentials needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds critical behavioral context beyond annotations: 'pure-local, NO network' and 'No credentials needed.' Annotations declare readOnlyHint and idempotentHint, but description clarifies no network calls or authentication required. 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?
Description is fairly concise, front-loading 'Reference (pure-local, NO network)'. Sentences are efficient but densely packed. Minor improvement could be more structured (e.g., bullet points), but still good.
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 no parameters and no output schema, the description fully covers what the tool provides: endpoints, operations, actions, codes, rates. Also distinguishes test vs production. Complete for an informational reference tool.
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?
No parameters. Baseline 4 per instructions. Description does not need to add parameter info as schema is empty and coverage is 100%.
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 it is a reference for DGI e-Factura endpoints, SOAP operations, document types, and IVA rates. It specifies it is pure-local and no network. This distinctively separates it from sibling tools which are action-oriented (build, submit, etc.).
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?
States 'so an agent can orient before signing' implying use before other DGI interactions. Also notes test endpoint is verified live and production must be confirmed. Lacks explicit exclusion of alternatives, but given siblings are actions, context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_envio_statusARead-onlyIdempotentInspect
Query the status of a previous DGI submission via the EFACCONSULTARESTADOENVIO webservice operation — e.g. to fetch the 2nd message (per-CFE response) using the consulta_token + consulta_fechahora that submit_sobre returned. Pass an ALREADY WS-Security-signed SOAP envelope (base64) whose Body wraps your signed consulta request; this server forwards it and returns the DGI response document. Safe/read-only at DGI. How signing works: DGI requires message-level WS-Security — you sign the CFE XML, build + sign the Sobre, and X.509-sign the SOAP envelope with your Uruguayan CA certificate (e.g. from Correo Uruguayo), all merchant-side. This server stores nothing and never sees your private key; it forwards the finished envelope. Endpoint headers: x-dgi-mode = test (default, ePrueba sandbox — no fiscal effect) | homologacion | produccion; or x-dgi-endpoint to point at an explicit DGI webservice URL. Owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools are honored.
| Name | Required | Description | Default |
|---|---|---|---|
| signed_soap_envelope | Yes | The FULL WS-Security-signed SOAP 1.1 envelope, base64-encoded. You build it (Body = the DGI operation wrapping <Datain><xmlData>your signed Sobre/Reporte</xmlData></Datain>), sign it with your X.509 certificate merchant-side, then base64-encode the whole envelope. This server forwards the bytes untouched — it never signs. Tip: call build_cfe_envelope first to get the exact Body to sign. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the server stores nothing, never sees private key, only forwards envelope, and explains the signing process. This goes well beyond annotations without 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 comprehensive but slightly verbose, with some background on signing that could be condensed. However, it is front-loaded with purpose and structured logically, earning its length.
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 no output schema, the description mentions returning the DGI response document but does not specify format (e.g., XML, base64). It covers inputs, headers, and behavior well, but output details are slightly lacking.
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% for one parameter. The description adds meaning: the envelope must be WS-Security signed, base64-encoded, with specific Body content, and that the server forwards it untouched. It also provides a tip to use build_cfe_envelope first.
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 it queries the status of a DGI submission via the EFACCONSULTARESTADOENVIO operation. It specifies fetching per-CFE responses using tokens from submit_sobre, distinguishing it from siblings like build_cfe_envelope and submit_sobre.
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 (after submit_sobre), mentions environment headers (x-dgi-mode) and owner-policy headers. It implicitly encourages using build_cfe_envelope first but does not explicitly state when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_reporte_diarioAInspect
Submit a Reporte Diario (daily report of the CFEs issued that day, including any anulados) to Uruguay DGI via the EFACRECEPCIONREPORTE webservice operation. Same shape as submit_sobre: pass an ALREADY WS-Security-signed SOAP envelope (base64) whose Body wraps your signed Reporte Diario XML; this server forwards it. Result carries the DGI acknowledgement (estado + any motivos_rechazo). The daily report is mandatory for emisores electrónicos. How signing works: DGI requires message-level WS-Security — you sign the CFE XML, build + sign the Sobre, and X.509-sign the SOAP envelope with your Uruguayan CA certificate (e.g. from Correo Uruguayo), all merchant-side. This server stores nothing and never sees your private key; it forwards the finished envelope. Endpoint headers: x-dgi-mode = test (default, ePrueba sandbox — no fiscal effect) | homologacion | produccion; or x-dgi-endpoint to point at an explicit DGI webservice URL. Owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools are honored.
| Name | Required | Description | Default |
|---|---|---|---|
| signed_soap_envelope | Yes | The FULL WS-Security-signed SOAP 1.1 envelope, base64-encoded. You build it (Body = the DGI operation wrapping <Datain><xmlData>your signed Sobre/Reporte</xmlData></Datain>), sign it with your X.509 certificate merchant-side, then base64-encode the whole envelope. This server forwards the bytes untouched — it never signs. Tip: call build_cfe_envelope first to get the exact Body to sign. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the server stores nothing, never sees private key, and forwards the envelope untouched. Describes endpoint headers and owner-policy headers. No contradictions with annotations (readOnlyHint=false, destructiveHint=false).
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?
Description is detailed but well-structured, front-loaded with purpose. Every sentence adds value, though could be slightly more concise. 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?
Given no output schema, description explains the result includes DGI acknowledgement. Covers endpoint configuration, security prerequisites, and mandatory usage context. Very complete for a complex tool.
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%, but description adds significant meaning: explains how to build the envelope (Body structure with DataIn/xmlData), signing process, tip to use build_cfe_envelope, and security model. Goes far 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 tool submits a Reporte Diario (daily CFE report) to Uruguay DGI via EFACRECEPCIONREPORTE. It specifies the action (submit), the resource (daily report), and distinguishes from sibling submit_sobre by noting 'Same shape as submit_sobre' but for a different purpose.
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?
Provides context: mandatory for emisores electrónicos, describes endpoint headers for environment selection. Does not explicitly state when not to use this tool or alternatives, but the comparison with submit_sobre implies differences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_sobreAInspect
Submit a Sobre (envelope of one or more signed CFEs — e-Factura / e-Ticket and their notas) to Uruguay DGI e-Factura via the EFACRECEPCIONSOBRE webservice operation. You pass an ALREADY WS-Security-signed SOAP envelope (base64); this server forwards it to DGI and translates the reply. Result: accepted=true with estado AS (Sobre Recibido — DGI accepted the envelope) or accepted=false with estado BS (Sobre Rechazado — see motivos_rechazo). On acceptance DGI returns consulta_token + consulta_fechahora — use them later with query_envio_status to fetch the 2nd message (per-CFE response). How signing works: DGI requires message-level WS-Security — you sign the CFE XML, build + sign the Sobre, and X.509-sign the SOAP envelope with your Uruguayan CA certificate (e.g. from Correo Uruguayo), all merchant-side. This server stores nothing and never sees your private key; it forwards the finished envelope. Endpoint headers: x-dgi-mode = test (default, ePrueba sandbox — no fiscal effect) | homologacion | produccion; or x-dgi-endpoint to point at an explicit DGI webservice URL. Owner-policy headers x-agentpay-max-amount / x-agentpay-approval-above / x-agentpay-allowed-tools are honored.
| Name | Required | Description | Default |
|---|---|---|---|
| signed_soap_envelope | Yes | The FULL WS-Security-signed SOAP 1.1 envelope, base64-encoded. You build it (Body = the DGI operation wrapping <Datain><xmlData>your signed Sobre/Reporte</xmlData></Datain>), sign it with your X.509 certificate merchant-side, then base64-encode the whole envelope. This server forwards the bytes untouched — it never signs. Tip: call build_cfe_envelope first to get the exact Body to sign. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: server forwards envelope without modification, never stores data, never sees private key, and returns specific fields (accepted, estado, motivos_rechazo, tokens). It aligns with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) and adds context about idempotency and side effects.
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 well-structured: starts with purpose, then result details, signing process, endpoint headers. It is concise relative to the complexity of the operation, though slightly lengthy. Every sentence adds essential information without redundancy.
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 complexity (Uruguay DGI SOAP, WS-Security signing, multiple modes, partial responses), the description provides comprehensive guidance. It explains acceptance/rejection states, tokens for follow-up, endpoint header options, and security constraints, making it sufficient for correct invocation without external references.
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?
The single parameter 'signed_soap_envelope' is already well-documented in the input schema (100% coverage). The description adds value by explaining how to construct it and referencing build_cfe_envelope for the body to sign, which aids correct usage beyond 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 states the action ('Submit a Sobre'), the resource (envelope of signed CFEs to Uruguay DGI), and the underlying webservice operation (EFACRECEPCIONSOBRE). It distinguishes from sibling tools like submit_reporte_diario (different endpoint) and build_cfe_envelope (prerequisite).
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 this tool: after building and signing the SOAP envelope, and it references build_cfe_envelope as a prerequisite. It also guides the agent on what to do with the result (use query_envio_status later). It does not explicitly state when not to use alternatives, but the context is 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!