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.
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.4/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: preview before emission, actual emission, SAT key lookup, and identity confirmation. No overlap or ambiguity.
Inconsistent naming: Spanish and English mixed (emitir_cfdi, preview_factura, resolver_claves_sat, whoami). Different verb styles and one single-word name break the pattern.
4 tools is well-scoped for an invoicing server covering preview, emission, key resolution, and identity. Not too few or too many.
Covers core emission workflow but lacks obvious operations like cancel, search, or list invoices, which are expected in a billing domain.
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: opcional pero RECOMENDADO. Si reintentas con la misma clave, NO se timbra
de nuevo: se devuelve el resultado original (evita CFDIs duplicados).| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adequately discloses key behaviors: real action, costly, hard to reverse, idempotency with idempotency_key (duplicate prevention), and logging. This is comprehensive for transparency.
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 relatively concise (6 sentences) and well-structured, with main action, usage instructions, and parameter list. A minor improvement would be to reduce redundancy in the parameter listing section.
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?
Given no output schema, the description does not explain the return value (e.g., CFDI XML or confirmation). It also lacks full detail on required parameters like conceptos. While it covers usage context well, it is incomplete regarding output format and validation, which a complex tool like this should include.
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 description coverage is 0%, so description must compensate. It explains observaciones, anticipo_id, and idempotency_key in detail, and references preview_factura for common arguments. While common args (cliente, conceptos, etc.) are not directly described, the reference is reasonable but relies on another tool's documentation, leaving a slight gap.
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 it emits and timbres an official CFDI 4.0 with SAT, specifying it's a real action with cost and difficulty to reverse. This explicitly distinguishes it from preview_factura and other siblings.
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 instructs to call preview_factura first and mentions API key limits and potential human approval, providing clear usage context. However, it does not explicitly state when not to use this tool or list alternatives beyond preview_factura.
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 y sin costo. Úsalo SIEMPRE antes de emitir_cfdi para confirmar el monto y que los datos pasen la validación.
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.| Name | Required | Description | Default |
|---|---|---|---|
| cliente | No | ||
| conceptos | Yes | ||
| emisor_id | No | ||
| cliente_id | No | ||
| forma_pago | No | 03 | |
| metodo_pago | No | PUE |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behavioral traits: it is a dry-run (no stamping, no cost), validates data, and calculates totals. However, it does not address error handling or side effects, though the preview nature suggests minimal impact. The core behavior is well communicated.
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 front-loaded with purpose and usage, followed by a structured parameter list. While effective, it is slightly verbose; for instance, 'sin timbrar y sin costo' is mentioned twice. Overall, each sentence adds value, but minor redundancy prevents a perfect score.
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 input parameters are thoroughly described, but the output is only hinted at ('calcula los totales (subtotal, IVA, retenciones, total)') without explicit format or return structure. Error handling and validation failure responses are not addressed. For a tool with no output schema, this leaves some gaps for the agent regarding what to expect after invocation.
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?
The input schema has 0% coverage, but the description provides detailed semantics for all parameters. For example, it specifies the structure for 'cliente' (including fields like rfc, nombre, regimen_fiscal) and 'conceptos' (including fields like descripcion, clave_prodserv, cantidad, valor_unitario). It also explains alternatives like cliente_id and provides default values. This adds significant meaning beyond the bare schema.
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's function: 'DRY-RUN: valida la factura y calcula los totales... SIN timbrar y sin costo.' It uses specific verbs ('valida', 'calcula') and resource ('factura'), and distinguishes it from sibling 'emitir_cfdi' by emphasizing it's a dry-run preview.
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 explicitly instructs: 'Úsalo SIEMPRE antes de emitir_cfdi para confirmar el monto y que los datos pasen la validación.' This provides clear when-to-use guidance and context, including that it's a no-cost validation step before the actual emission.
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).| Name | Required | Description | Default |
|---|---|---|---|
| con_iva | No | ||
| descripcion | Yes | ||
| unidad_hint | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It describes what the tool returns (sugerencia and candidatos), but does not state whether it is idempotent, read-only, or any side effects. For a resolver, this is adequate but not comprehensive.
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 concise, with four sentences plus parameter docs. It front-loads the core purpose and then covers return format, usage guidance, and parameter details without unnecessary text. Every sentence adds value.
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?
Given the tool has no output schema, the description adequately explains the return values (sugerencia fields and candidatos). It also provides parameter examples. However, it does not mention error handling or what happens if no match is found, which would improve completeness.
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 description coverage is 0%, so the description must add meaning. It provides clear descriptions and examples for each parameter (descripcion: examples of natural language inputs; unidad_hint: examples like 'servicio', 'hora'; con_iva: default and meaning of IVA 16%). This fully compensates for the missing schema descriptions.
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 converts natural language descriptions to SAT keys for invoicing, using the verb 'convierte' and specifying the resource 'claves del SAT'. It distinguishes from siblings like emitir_cfdi and preview_factura, which are downstream tools.
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 explicitly says 'Llámalo antes de armar un concepto si no conoces las claves', providing clear when-to-use guidance. It does not explicitly mention when not to use or alternatives, but the context of sibling tools is clear enough.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description openly discloses the tool's read-only diagnostic behavior and the information it returns.
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?
Concise, front-loaded, and efficient; each sentence adds value 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?
Fully adequate for a zero-parameter diagnostic tool, covering purpose and usage.
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?
The tool has no parameters, so schema coverage is 100%. The description adds no parameter info, which is appropriate.
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 confirms the agent's identity, including business, permissions, limits, and usage, distinguishing it from sibling tools like emitir_cfdi or preview_factura.
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 explicitly recommends using the tool to diagnose the connection, providing clear context for use.
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!