A
license-
qualityB
maintenanceEnables AI agents to issue Mexico CFDI 4.0 electronic invoices (factura electrónica) via Facturapi, with tools for creating, querying, canceling, and sending invoices.
MIT
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.
- 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.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.4/5.0
Tool DescriptionsA
Average 4.6/5 across 4 of 4 tools scored.
Server CoherenceA
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 toolsemitir_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 | Description | 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 |
Tool Definition Quality
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 | Description | Default |
|---|---|---|---|
| cliente | No | ||
| conceptos | Yes | ||
| emisor_id | No | ||
| cliente_id | No | ||
| forma_pago | No | 03 | |
| anticipo_id | No | ||
| metodo_pago | No | PUE |
Tool Definition Quality
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 |
Tool Definition Quality
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 | |||
Tool Definition Quality
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.
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!
Related MCP Servers
- Alicense-qualityBmaintenanceEnables AI agents to issue Chilean electronic tax documents (boleta and factura) stamped at SII via OpenFactura, with stateless bring-your-own-credentials.MIT
Tlaloc MCP Serverofficial
Alicense-qualityBmaintenanceProvides AI assistants with live, authenticated access to official Mexican data sources including CURP, RFC, postal codes, phone numbers, SPEI payments, CFDI status, DOF semantic search, and geocoding via INEGI/INE.MIT- Alicense-qualityCmaintenanceEnables AI agents to submit Uruguay DGI e-Factura (CFE) documents to the DGI webservice as a stateless forwarder; signing stays merchant-side, and it supports test, homologation, and production endpoints.MIT