mcp-cfdi-mx

Overview Schema Source Related Servers Discussions Admin

Mx Get Supported Scope

mx__get_supported_scope

Check supported CFDI document types, complementos, and sealing modes before generating, validating, sealing, or verifying invoices.

Instructions

Return the CFDI document types, complementos, and sealing modes this package supports.

Reflects Phase 1 scope: CFDI 4.0 Ingreso + Egreso + Complemento de Pagos 2.0, PAC-agnostic sealing. Build (mx__build_cfdi/mx__build_pago), XSD validation (mx__validate_cfdi), sealing (mx__seal_cfdi), and TFD verification (mx__verify_tfd) are all implemented. PAC submission transport and later-phase complementos are not.

Returns: A ScopeInfo describing current scope, for callers to check before assuming a document type or complemento is supported.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`phase`	Yes	Package's own delivery-phase number
`out_of_scope`	No	Capabilities deliberately not implemented yet
`sealing_modes`	Yes
`schema_version`	Yes	Wire-format schema version this package targets
`supported_complementos`	Yes
`supported_document_types`	No	Document-type codes supported today

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.4.0Sep 9, 2026

addedOutput schema / description

Added value: +"MX's own scope fields on top of the shared base (core v1.32.0, CORE-8).\n\nAdds `supported_complementos` (Complemento de Pagos, Comercio Exterior,\netc.) and `sealing_modes` (`local`/`pac`) — CFDI-specific dimensions the\nshared base does not know about. `version` is renamed `schema_version`\nto match the base field name."

addedOutput schema / properties / out_of_scope / description

Added value: +"Capabilities deliberately not implemented yet"

addedOutput schema / properties / phase / description

Added value: +"Package's own delivery-phase number"

addedOutput schema / properties / schema_version

Added value: +{
+  "description": "Wire-format schema version this package targets",
+  "type": "string"
+}

addedOutput schema / properties / supported_document_types / description
```
Added value: +"Document-type codes supported today"
```

removedOutput schema / properties / version

Removed value: -{
-  "type": "string"
-}

changedOutput schema / required

Previous value: -[
-  "version",
-  "phase",
-  "supported_document_types",
-  "supported_complementos",
-  "sealing_modes",
-  "out_of_scope"
-]New value: +[
+  "schema_version",
+  "phase",
+  "supported_complementos",
+  "sealing_modes"
+]

First observedv0.3.0Sep 5, 2026

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it does disclose the most consequential behavioral trait: this reports a static Phase 1 capability surface, not live PAC state, and specifically excludes PAC submission transport and later-phase complementos. Auth requirements, rate limits, and freshness of the scope data are not addressed, so it stops short of a 5.

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?

Front-loads the core purpose in the first sentence, then enumerates implemented vs missing capabilities in a compact parenthetical list that earns its space by preempting wrong-tool selection. The trailing 'Returns:' block partially restates what the output schema (ScopeInfo) already declares, which is mild redundancy.

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?

Complete for a zero-argument scope-report tool. The output schema covers the return shape, so the description correctly spends its budget on what the schema cannot convey: which capabilities are live in this phase and which are deliberately absent.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline for an argument-free tool is 4. Schema coverage is 100% and the empty object schema is unambiguous.

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?

Precise verb+resource ('Return the CFDI document types, complementos, and sealing modes this package supports') with the exact return type named. It explicitly scopes itself against siblings by listing which of mx__build_cfdi, mx__validate_cfdi, mx__seal_cfdi, mx__verify_tfd are implemented and which capabilities are absent, so an agent can distinguish it without opening a schema.

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?

States the trigger condition clearly: callers should check before assuming a document type or complemento is supported. It also discloses the negative cases (PAC submission transport and later-phase complementos are not implemented), which prevents misuse. It stops short of naming an alternative tool for any adjacent need, but no sibling covers this capability-check role.

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

Deploy Server