Chile Invoices (DTE boleta/factura electrónica via OpenFactura)
Server Details
Chile DTE for AI agents - issue boleta/factura electronica via OpenFactura (SII). Stateless BYO.
- Status
- Healthy
- 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.8/5 across 3 of 3 tools scored.
Each tool targets a distinct operation: creating, canceling, or querying invoices. There is no functional overlap between the tools.
All tool names follow a consistent verb_noun pattern (cancel_invoice, create_invoice, query_invoice), making it predictable.
Three tools is on the low end for an invoicing system, but each serves a clear purpose. However, a more complete set would typically include listing or searching invoices.
The surface covers create, read, and cancel, but missing list/search functionality, which is a notable gap for managing invoices. No update is acceptable since DTE documents are immutable.
Available Tools
3 toolscancel_invoiceADestructiveInspect
Void a Chile DTE by issuing a nota de crédito electrónica (TipoDTE 61) that references the original with CodRef=1 (anula documento) — this is the SII-correct way to cancel; there is no delete. Pass the original document_type + folio; the credit note mirrors the original net amount and reverses it. Returns the credit-note folio. Runs in the same mode (dev/production) as the header x-openfactura-mode.
| Name | Required | Description | Default |
|---|---|---|---|
| folio | Yes | The folio of the document to void (as returned by create_invoice). | |
| reason | No | Optional reason text (RazonRef), max 90 chars. Default "Anula documento". | |
| document_type | Yes | DTE type of the document to void: 33 factura or 39 boleta. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the exact mechanism (creating a credit note that references the original with CodRef=1), the fact that it mirrors and reverses the net amount, and that it returns the credit-note folio. This provides comprehensive behavioral insight beyond the destructiveHint annotation.
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 very concise, consisting of two sentences that front-load the purpose and method. Every sentence adds value, covering what, how, what to pass, what is returned, and environment context, with no 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?
The description is complete for this tool: it explains the return value (credit-note folio) despite no output schema, clarifies the parameters in context, mentions the environment mode, and provides enough context to distinguish from siblings. No gaps are apparent.
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 parameters are already well described. The description adds context by explaining that document_type and folio identify the original document and that the credit note mirrors the net amount, enhancing understanding of how the parameters are used.
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 voids a Chile DTE by issuing a credit note, specifying the exact DTE type (61) and CodRef=1. It distinguishes from a hypothetical delete operation and implicitly differentiates from siblings create_invoice and query_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 explains that this is the SII-correct way to cancel and that there is no delete, providing clear usage context. It also notes the environment mode (dev/production) from the header. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_invoiceAInspect
Issue a Chile electronic tax document (DTE) through OpenFactura (Haulmer): a boleta electrónica (consumer receipt, TipoDTE 39, default) or a factura electrónica (B2B invoice, TipoDTE 33), stamped against SII with the merchant's own CAF. Bring your own OpenFactura API key via header x-openfactura-key. Runs against the OpenFactura DEV sandbox by default (no fiscal effect); send header x-openfactura-mode: production to emit real SII documents. The Emisor (your company RUT, razón social, giro, address) is auto-derived from your account — you do not pass it. Amounts are in CLP (Chilean pesos: whole integers, no decimals). IMPORTANT price convention: for a boleta (39) each price is GROSS (IVA 19% already included, as shown to consumers); for a factura (33) each price is NET (IVA 19% is added on top).
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Line items. Each: description, price (CLP integer — GROSS for boleta, NET for factura), optional quantity (default 1). | |
| customer_rut | No | Buyer RUT, format 12345678-9 (check digit 0-9 or K). REQUIRED for a factura (33). For a boleta (39) it is optional and defaults to the generic consumer 66666666-6. | |
| customer_giro | No | Buyer giro (business activity). Factura (33) only; SII expects it for B2B. Default "Particular". | |
| customer_name | No | Buyer razón social / name. Required for a factura (33); defaults to "Consumidor Final" for a boleta. | |
| document_type | No | DTE type: 39 = boleta electrónica (consumer, prices GROSS/IVA-included) — default; 33 = factura electrónica (B2B, prices NET/IVA-added). Cannot issue 61 here — use cancel_invoice to void via a credit note. | |
| customer_comuna | No | Buyer comuna (CmnaRecep). Factura (33) only. Default "Santiago". | |
| customer_address | No | Buyer street address (DirRecep). Factura (33) only. Default "Sin direccion". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) with no destructive hint. Description adds context: requires API key, defaults to sandbox, auto-derives merchant data, and explains price conventions. 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?
Somewhat lengthy but well-structured and front-loaded. Every sentence adds necessary detail; minor redundancy could be trimmed but remains clear.
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?
No output schema, but description explains result (stamped document), sandbox vs production, and covers all parameters. Agent has sufficient context to use correctly.
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 critical meaning: gross vs net price based on document_type, customer_rut requirement difference, defaults for boleta vs factura, and format constraints.
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 issues Chile electronic tax documents (DTE) via OpenFactura, specifying boleta (39) and factura (33) types, and distinguishes from siblings cancel_invoice and query_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?
Explicitly explains when to use boleta vs factura, requires x-openfactura-key header, sandbox vs production, auto-derived emisor, price conventions, and notes that credit notes are handled by cancel_invoice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_invoiceARead-onlyInspect
Fetch a DTE you emitted (by document_type + folio) from OpenFactura. Status values: ISSUED (accepted by OpenFactura, awaiting/without an SII acceptance timestamp), ACCEPTED_BY_SII (SII reception timestamp present). Returns the receptor, net/IVA/total (CLP). Safe to call anytime. (OpenFactura resolves your Emisor RUT from the API key automatically.)
| Name | Required | Description | Default |
|---|---|---|---|
| folio | Yes | The folio returned by create_invoice (or cancel_invoice for a 61). | |
| document_type | Yes | DTE type of the document to fetch: 33 factura, 39 boleta, 61 credit note. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint and openWorldHint. The description adds that it is 'safe to call anytime' and explains automatic RUT resolution, plus detailed status meanings. This provides 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 two sentences, front-loaded with the main purpose, and every sentence adds useful 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?
For a tool with only two parameters, no output schema, and clear annotations, the description covers all necessary aspects: what it does, how to call it, status codes, response contents, and safety.
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. The description adds value by specifying that folio comes from create_invoice or cancel_invoice and enumerating DTE types, making parameters clearer despite schema already covering them.
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 starts with 'Fetch a DTE you emitted (by document_type + folio) from OpenFactura.' This is a specific verb (fetch) and resource (DTE), and the tool is clearly distinguished from siblings create_invoice and cancel_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 indicates when to use (after creating or canceling), explains status values and return fields, but does not explicitly state when not to use or name alternatives. However, the context is clear enough for an agent.
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!