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 by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.9% over 43 days
Last Tested: 2026-09-29 22:44
Transport: Streamable HTTP · MCP 2025-11-25
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.

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

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 3 months ago (2026-07-11 05:47 UTC)
MIT
mx-fiscal-mcp-server
Finance Government Data Legal & Compliance
OrtaMarco
A
license
A
quality
A
maintenance
Enables AI agents to validate Mexican RFC, CURP, CLABE and NSS identifiers with real check digits, parse CFDI 4.0 invoices with labelled SAT catalogue codes and verified totals, and query the SAT's public status service to see whether an invoice is still valid. It also generates coherent test people and companies, all read-only and without API keys, certificates or PAC contracts.
Updated 16 days ago (2026-09-14 03:40 UTC)
8
51 npm
1
MIT
@timbrix/mcp
Finance Payments & Billing Legal & Compliance
Timbrix
A
license
A
quality
C
maintenance
Enables AI agents to stamp, cancel, and query Mexican CFDI 4.0 invoices through MCP tools, with support for local stdio and hosted HTTP transport.
Updated 11 days ago (2026-09-18 23:08 UTC)
4
220 npm
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 2 days ago (2026-09-27 16:24 UTC)
121
64 npm
2
MIT