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: 100.0% over 64 days
Last Tested: 2026-10-20 11:55
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.1/5.0

Scored 2026-10-02 05:40 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: preview_factura is a dry-run validation, emitir_cfdi performs the real emission, resolver_claves_sat resolves SAT keys, and whoami checks identity. There is no overlap that would cause misselection.

Naming Consistency3/5

Names use snake_case throughout, but verb conventions are mixed: Spanish verbs (emitir, resolver), an English verb (preview), and a single-token command (whoami). This is still readable but not fully consistent.

Tool Count4/5

4 tools is a reasonable number for a focused invoicing API, covering the emission workflow (preview, emit), auxiliary key resolution, and identity check. It could arguably be slightly under-scoped for full invoice management, but not excessively.

Completeness2/5

The tool surface lacks critical lifecycle operations: no way to cancel an emitted CFDI, query its status, or list past invoices. This will cause agent failures when managing invoices after emission.

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 o el estado de verificación. Con 504
        PAC_SIN_CONFIRMACION o 409 CFDI_EN_VERIFICACION, reintenta más tarde con la
        MISMA clave y nunca con otra; 409 OPERACION_CERRADA pide una clave nueva; 409
        CFDI_YA_EMITIDO significa que ya existe.

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.1/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers rich behavioral context: real irrevocable/costly action, API key limits, possible human approval, audit logging, mandatory production idempotency, and retry semantics for 504/409 cases. It clearly discloses the operational risks and constraints an agent must know.

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 dense but front-loaded with the core warning and preview dependency, then moves into arguments and idempotency details. The long idempotency paragraph is justified by the lack of annotations and schema descriptions, though the structure could be slightly tighter.

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?

For a complex, dangerous, 9-parameter tool with no annotations, no output schema, and 0% schema description coverage, the definition is strong on behavior but incomplete on parameters and return expectations. It tells the agent to mirror preview_factura for most inputs, but an agent would need that sibling schema to call this tool correctly.

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

Parameters2/5

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

Schema coverage is 0% for 9 parameters, and the description only explains three of them: observaciones, anticipo_id, and idempotency_key. The remaining parameters, including the required conceptos plus cliente, emisor_id, cliente_id, forma_pago, and metodo_pago, are delegated to 'iguales a preview_factura,' which is not self-contained parameter documentation.

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 names a specific verb and resource: 'Emite y timbra un CFDI 4.0 OFICIAL ante el SAT.' It also states the scope ('acción real, con costo y difícil de revertir') and directly distinguishes the tool from its sibling by instructing the caller to use preview_factura first.

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 names preview_factura as the required predecessor and gives detailed retry guidance around idempotency, plus behavioral context for production use. It does not spell out a full when-not-to-use rule beyond the implied warning, but the intended usage sequence is clear.

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 13 days ago (2026-10-07 01:50 UTC)
8
187 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 a month ago (2026-09-18 23:08 UTC)
4
453 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-10-18 16:24 UTC)
131
20 npm
2
MIT