Notsy Facturación

Server Details

Emite CFDIs 4.0 y resuelve claves del SAT para agentes de IA (México), con permisos por API key.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-09 06:26
Transport: Streamable HTTP
URL

TDQS

A4.4/5.0

Scored 2026-08-17 09:00 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: preview_factura is a dry-run, emitir_cfdi actually timbres, resolver_claves_sat finds SAT keys, and whoami checks identity. No overlap in functionality.

Naming Consistency4/5

Most tools follow a Spanish verb_noun pattern (emitir_cfdi, resolver_claves_sat), but preview_factura uses an English verb and whoami is a Unix command, introducing minor inconsistency.

Tool Count5/5

With only 4 tools, the set is well-scoped for a focused invoicing server: preview, emit, key resolution, and authentication. Each tool earns its place without bloat.

Completeness3/5

The core workflow (preview and emit CFDI) is covered, but the server lacks operations for canceling CFDIs, listing past emissions, or managing clients/anticipos, which are part of a full invoicing lifecycle.

Available Tools

4 tools

emitir_cfdiAInspect

Emite y timbra un CFDI 4.0 OFICIAL ante el SAT (acción real, con costo y difícil de revertir). Llama primero a preview_factura. El motor aplica los límites de la API key (puede requerir aprobación humana) y registra la acción en la bitácora.

Args: iguales a preview_factura, más:
    observaciones: texto libre opcional en el CFDI.
    anticipo_id: opcional, id de un anticipo previo a aplicar (relación 07 + nota de crédito).
    idempotency_key: OBLIGATORIA en producción (genera un UUID por operación y reúsalo en
        los reintentos). Si reintentas con la misma clave, NO se timbra de nuevo: se
        devuelve el resultado original (evita CFDIs duplicados ante el SAT).

ParametersJSON Schema

Name	Required	Default
`cliente`	No
`conceptos`	Yes
`emisor_id`	No
`cliente_id`	No
`forma_pago`	No	03
`anticipo_id`	No
`metodo_pago`	No	PUE
`observaciones`	No
`idempotency_key`	No

TDQS

A4.2/5.0

Behavior5/5

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

No annotations provided, so description carries full burden. It discloses real action with cost, difficulty to revert, logging, human approval possibility, and idempotency behavior (no duplicate stamping). This is comprehensive and exceeds minimum.

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?

Description is well-structured with a purpose paragraph followed by parameter list. Front-loaded with important caveats. Slightly long but every sentence serves a purpose.

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?

Given complexity (9 params, no output schema), description covers key behavioral traits but lacks full parameter detail and return value explanation. Relies on sibling tool for base args, which may not be self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It explains three new parameters (observaciones, anticipo_id, idempotency_key) but relies on referencing 'preview_factura' for the rest. This adds value but leaves some parameters unexplained in isolation.

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 clearly states it 'Emite y timbra un CFDI 4.0 OFICIAL ante el SAT' with explicit mention of cost and difficulty to revert. It distinguishes itself from sibling 'preview_factura' by noting it's the actual action, not a preview.

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 explicitly instructs users to call 'preview_factura' first, and mentions API key limits, human approval, and idempotency key for retries. This provides clear usage context, though it does not explicitly list when to avoid using this tool.

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

preview_facturaAInspect

DRY-RUN: valida la factura y calcula los totales (subtotal, IVA, retenciones, total) SIN timbrar, reservar ni cobrar. También devuelve la cotización canónica de créditos y el saldo proyectado. Úsalo SIEMPRE antes de emitir_cfdi para confirmar el monto, el costo y que los datos pasen la validación. Aplicar un anticipo cotiza dos CFDI (ingreso + egreso).

Args:
    conceptos: lista de conceptos. Cada uno: {descripcion, clave_prodserv, clave_unidad,
        cantidad, valor_unitario, precio_incluye_iva (bool), tasa_iva (0.16/0.08/0.0),
        objeto_imp ("02"), retencion ("honorarios"|"arrendamiento"|"comisiones"|"fletes"|"")}.
    cliente: datos del receptor {rfc, nombre, regimen_fiscal, cp, uso_cfdi, email,
        es_publico_general} — o usa cliente_id si ya está guardado.
    cliente_id: id de un cliente guardado (alternativa a `cliente`).
    forma_pago: clave SAT de forma de pago (default "03" transferencia).
    metodo_pago: "PUE" (de contado) o "PPD" (a crédito).
    emisor_id: opcional, desde qué RFC emitir (multiemisor); None = predeterminado.
    anticipo_id: opcional, anticipo previo a aplicar; cotiza dos CFDI.

ParametersJSON Schema

Name	Required	Default
`cliente`	No
`conceptos`	Yes
`emisor_id`	No
`cliente_id`	No
`forma_pago`	No	03
`anticipo_id`	No
`metodo_pago`	No	PUE

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and excels. It explicitly states the tool does NOT timbrar, reservar, nor cobrar, and promises a projected balance and credit quote. It also discloses that applying an anticipo results in two CFDI quotes, providing behavioral nuance beyond a simple 'preview' label.

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 well-structured with a bolded summary head and a clear Args list, but it contains some redundancy: the anticipo multi-CFDI note appears both in the main paragraph and in the anticipo_id argument. Despite this minor repetition, every sentence adds value for a tool of this complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description covers the tool's purpose, usage timing, all parameters, and key outputs (totals, cotización, saldo). It also clarifies an optional pattern (cliente_id vs. cliente). This provides a complete mental model for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description's 'Args' section meticulously documents all seven parameters. It specifies the full object structure for conceptos and cliente, valid values for metodo_pago, defaults for forma_pago, and optionality for emisor_id. This fully compensates for the lack of schema-level descriptions.

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 opens with 'DRY-RUN' and clearly states the tool validates the invoice and calculates totals (subtotal, IVA, retenciones, total) without stamping, reserving, or charging. This distinguishes it from the sibling tool emitir_cfdi, and even mentions an edge case (anticipo quotes two CFDI), making the purpose extremely clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs 'Úsalo SIEMPRE antes de emitir_cfdi para confirmar el monto, el costo y que los datos pasen la validación.' This names the exact alternative and provides a concrete when-to-use rule. It also explains the multi-CFDI behavior with anticipos, further guiding usage.

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

resolver_claves_satAInspect

Convierte una descripción en lenguaje natural a las claves del SAT necesarias para facturar.

Devuelve `sugerencia` con clave_prodserv, clave_unidad, objeto_imp, tasa_iva y uso_cfdi, más
`candidatos` por si quieres elegir otra. Llámalo antes de armar un concepto si no conoces las claves.

Args:
    descripcion: qué se vende, p.ej. "consultoría de marketing" o "laptop Dell".
    unidad_hint: opcional, unidad de medida en palabras ("servicio", "hora", "pieza", "kg").
    con_iva: si el producto/servicio causa IVA 16% (default True).

ParametersJSON Schema

Name	Required	Description	Default
`con_iva`	No
`descripcion`	Yes
`unidad_hint`	No

TDQS

A4.6/5.0

Behavior4/5

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

No annotations are provided, so the description bears full responsibility. It discloses that the tool returns a 'sugerencia' with specific fields (clave_prodserv, clave_unidad, etc.) and 'candidatos' for alternative choices. It does not mention side effects, authorization, or rate limits, but for a simple query/transformation tool, the transparency is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a clear opening sentence, a concise output summary, a usage directive, and a parameter list. No unnecessary words or repetition. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters, no output schema, and no annotations, the description provides sufficient context. It covers purpose, usage timing, parameter details, and the nature of the return values (suggestion with specific fields and candidates). No critical information appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully explains all three parameters: 'descripcion' as 'qué se vende', 'unidad_hint' as 'opcional, unidad de medida en palabras', and 'con_iva' as 'si el producto/servicio causa IVA 16% (default True)'. This adds essential meaning beyond the schema's field names alone.

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 explicitly states it converts a natural language description to SAT keys for invoicing, with a specific verb ('Convierte') and resource ('descripción a claves del SAT'). It clearly distinguishes from sibling tools (emitir_cfdi, preview_factura, whoami) which are about different operations like emitting or previewing invoices.

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?

The description provides clear usage context: 'Llámalo antes de armar un concepto si no conoces las claves.' It tells when to call the tool (when keys are unknown) and implies it should be used before building an invoice concept. However, it does not explicitly state when not to use it or mention alternative tools, though the sibling tools are sufficiently different.

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

whoamiAInspect

Confirma la identidad del agente: a qué negocio pertenece la API key, sus permisos (scopes), límites de emisión y uso del día. Úsalo para diagnosticar la conexión.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description must cover behavior. It reveals that the tool returns business info, scopes, limits, and usage data, implying it is a read-only diagnostic. It does not mention any side effects, which is acceptable for a read-only tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loading the purpose and ending with usage guidance. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description sufficiently explains the return values (business, scopes, limits, usage). It provides complete context for a zero-parameter diagnostic tool.

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?

There are no parameters (0 params, baseline 4). The description adds no parameter details, but none are needed.

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 clearly states the tool's purpose: confirming agent identity, business, scopes, emission limits, and daily usage. It distinguishes from sibling tools like emitir_cfdi, preview_factura, and resolver_claves_sat by focusing on connection diagnostics.

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 explicitly says 'Úsalo para diagnosticar la conexión' (use it to diagnose the connection), which provides clear guidance on when to use. However, it does not specify when not to use or suggest alternative tools.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

1 tool updateAug 17, 2026

Changedpreview_factura1 field changed

addedInput schema / properties / anticipo_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Anticipo Id"
+}

4 tool updatesJun 9, 2026
- First observedemitir_cfdi
- First observedpreview_factura
- First observedresolver_claves_sat
- First observedwhoami

Frequently Asked Questions

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
- GitHub identity – fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
- HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
- DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

Mexico Invoices (CFDI 4.0 factura electrónica)A
app.wishpool
Mexico CFDI 4.0 invoices for AI agents - issue, query, cancel facturas via Facturapi.
Finance Payments & Billing
2
Peru Invoices (CPE factura/boleta electrónica, SUNAT)A
app.wishpool
Peru CPE invoices for AI agents - issue, query, void facturas/boletas via SUNAT (2 backends).
Finance Payments & Billing Legal & Compliance
2
Cobra · Facturación SRI Ecuador
com.facturacobra
Emite facturas, notas y retenciones del SRI de Ecuador con lenguaje natural.
Finance Payments & Billing Legal & Compliance
2
tlaloc-mcpOAuth
io.github.tlaloc-sh
Official Mexican data for AI agents: CURP, RFC, CFDI, postal codes, phone, SPEI/CEP, DOF, geocoding.
Government Data Open Data
2

Related MCP Servers

Mexico Invoice MCP
Finance Payments & Billing
junter1989k-ai
A
license
Not graded
quality
B
maintenance
Enables AI agents to issue Mexico CFDI 4.0 electronic invoices (factura electrónica) via Facturapi, with tools for creating, querying, canceling, and sending invoices.
Updated 2 months ago (2026-07-11 05:47 UTC)
MIT
BeeL MCP serverofficial
Finance Legal & Compliance Payments & Billing
beel-es
A
license
A
quality
A
maintenance
Enables AI agents to issue, correct, and register legally compliant Spanish electronic invoices with AEAT VeriFactu, supporting F1/F2 types, R1–R5 correctives, and NIF validation from Claude, ChatGPT, Cursor, or VS Code.
Updated 3 days ago (2026-09-06 16:24 UTC)
121
120
2
MIT
chile-invoice-mcp
Finance Payments & Billing Legal & Compliance
junter1989k-ai
A
license
Not graded
quality
B
maintenance
Enables AI agents to issue Chilean electronic tax documents (boleta and factura) stamped at SII via OpenFactura, with stateless bring-your-own-credentials.
Updated 2 months ago (2026-07-11 05:45 UTC)
MIT
mcp-cfdi-mx
Payments & Billing Legal & Compliance
cmendezs
A
license
A
quality
A
maintenance
Model Context Protocol (MCP) server for Mexican Electronic Invoicing (CFDI 4.0, Complemento de Pagos 2.0). Provide tools to validate, generate, and explore API specifications for SAT/PAC interoperability.
Updated a day ago (2026-09-07 21:19 UTC)
6
Apache 2.0