mexicoapi 0.2.0

Cambios de comportamiento. Revisa tu código si usas lo que nombran:

• diasHabiles del cliente revisa tipoPlazo antes de ir a la red o al paquete: con el SAT sin él, con otra autoridad y con él, o con un valor que no es general ni declaraciones_pagos, lanza TypeError (que nombra tipoPlazo) en lugar de MexicoApiError. consultar("/v1/dias-habiles", …) sigue dando el MexicoApiError de la API, con tipo_plazo.
• Las advertencias de primer nivel del cliente traen también las del cálculo (data.advertencias de diasHabiles), al final y sin repetidos; data.advertencias no cambia. Si las juntabas a mano ([...advertencias, ...data.advertencias]), tendrás repetidas: usa solo advertencias.
• sumarDiasHabiles con calendario("sat", "general") y permitirIncompleto: true sigue con el respaldo del plazo, como la API: del 2026-12-23, 2 días hábiles dan el 2026-12-28 (antes, el 25, inhábil por el art. 12), con la advertencia de la API.
• Cada validador tiene su propia nota: la de la CLABE ya no nombra al SAT, RENAPO ni el IMSS y, sin catálogo de bancos, dice que no revisó el banco. NOTA_VALIDACION sigue exportada, pero ningún validador la usa y queda obsoleta: usa NOTAS_VALIDACION.
• fixUltimo() respondido con los datos del paquete (sin red, con fuente: "paquete" o de respaldo) trae siempre la advertencia AVISO_SIN_API: pueden faltar publicaciones recientes.
• Con el SAT y declaraciones_pagos, advertencia nueva cuando el resultado cae fuera de las vacaciones publicadas: ese día podría ser de vacaciones y aplicaría la prórroga del art. 12. El resultado no cambia.
• Los días de la LFT anteriores al 2024-10-01 (diasDescansoLft, calendarioLft y el cliente) citan el texto del art. 74 vigente entonces, el de la reforma del DOF 17-01-2006 (fracción VII: "1o. de diciembre"), con su fecha_publicacion; antes citaban el texto actual. Las fechas no cambian.
• El cliente ya no sigue redirecciones. Pide con redirect: "manual" (también el InitFetch que recibe un fetch propio) y una 3xx de la API, salvo 304, es un MexicoApiError "Respuesta inesperada de la API" con su estado HTTP (estado 0 si el navegador da una redirección opaca), sin reintentos; en las rutas que caducan responde el paquete con la advertencia de respaldo. Antes fetch seguía la redirección.
• El cliente lee el cuerpo de la respuesta con un tope de 8 MB y revisa que data sea una lista o un objeto según la ruta: lo que no cumple también es "Respuesta inesperada de la API". RespuestaFetch acepta body (un ReadableStream, para leer por partes) y type.
• CLI: MEXICOAPI_SIN_RED acepta 1, true, yes, si u on para no usar la red y 0, false, no, off o vacía para consultar la API, sin distinguir mayúsculas, como el servidor MCP. Antes solo 1 apagaba la red y cualquier otro valor la dejaba encendida; ahora otro valor es un error de configuración (sale con 2, sin el recordatorio de --help) en los comandos que usan el cliente, aunque haya --base.
• CLI: dias-habiles exige --autoridad (lft, cnbv o sat), como la API y el servidor MCP; sin ella sale con 2. Antes usaba la LFT si no se daba. Si tus scripts la omitían, agrega --autoridad lft para el mismo resultado.
• CLI: un error de uso (código 2) termina con la ayuda de su comando, Usa mexicoapi dias-habiles --help para ver su uso. (o mexicoapi sepomex cp --help); solo sin comando, o con uno que no existe, con Usa mexicoapi --help para ver los comandos. Antes siempre con la general.
• Textos más claros: el 422 del SAT general fuera de su cobertura sugiere permitir_incompleto=true y nombra declaraciones_pagos solo para plazos de declaraciones o pagos; el 404 del FIX con publicado en un día sin publicación sugiere operacion. La CLI muestra esos errores con sus opciones (--tipo-plazo, --permitir-incompleto) y rechaza con su nombre un --tipo-plazo que no existe.
• validarCurp: la posición 17 (el diferenciador) solo acepta un dígito o una letra de la A a la J, como dice el Instructivo Normativo de la CURP (DOF 18-06-2018). Con una letra de la K a la Z da valido: false y errores: ["estructura"]; antes se aceptaba cualquier letra.
• crearCliente lanza TypeError con una base http:// que no sea localhost, 127.0.0.1 o [::1], con puerto o sin él; para otro host, usa https://. La CLI da el mismo error con --base o MEXICOAPI_BASE así, salvo en los comandos que no usan el cliente (los validadores, sepomex y municipio con un nombre) o, con MEXICOAPI_BASE, sin red (MEXICOAPI_SIN_RED). Sale con 2, como un error de configuración.
• TipoProblema (de mexicoapi y mexicoapi/cliente) y PROBLEMAS (de mexicoapi/cliente) suman el tipo https-requerido: la API responde 403 con él a una petición por http:// a un host que no es local. Un switch exhaustivo sobre TipoProblema tiene un caso más.

Nuevo:

• banco_revisado en el resultado de validarClabe (false si no se pasa el catálogo de bancos; bancos: null cuenta como no pasarlo, como en la 0.1.0) y en clabe() del cliente (siempre true, como la API). Tipo ResultadoValidacionClabe.
• CLI: fix [--operacion AAAA-MM-DD | --publicado AAAA-MM-DD] (sin opciones, la publicación más reciente) y udi <AAAA-MM-DD>, con la fuente, el pie de origen y --json (la respuesta del cliente, con los avisos). Como los demás datos que caducan, consultan la API y, si no responde, usan el paquete y lo avisan. Un error de la API que sugiere operacion= se muestra con --operacion.
• CLI: estados (las 32 entidades con su clave y abreviatura) y municipios <cve_ent> (todos los municipios de un estado, con el total), del paquete y sin red, en texto y con --json. municipio 25, que busca por nombre y no encuentra nada, sugiere mexicoapi municipios 25.
• hoyEnMexico(): la fecha de hoy en la Ciudad de México, la zona de todas las fechas de MéxicoAPI.
• NOTAS_VALIDACION, AVISO_SIN_API, el tipo RespaldoCalendario y Calendario.respaldo.
• avisos junto a cada advertencias: las mismas, en el mismo orden, como { codigo, texto }, con un código estable para decidir sin leer el texto. Están en las respuestas del cliente (y en data.avisos de diasHabiles), en el resultado de sumarDiasHabiles (campo nuevo de ResultadoDiasHabiles) y en resumen() de mexicoapi/sepomex. CODIGOS_AVISO y codigoAviso() dan el catálogo y el código de un texto; tipos Aviso y CodigoAviso. Si la API manda el código de un aviso, el cliente lo conserva; si no, lo saca del texto. Los códigos del cliente y de SEPOMEX: api-fallo, respuesta-guardada, datos-viejos, datos-del-paquete, municipio-sin-inegi, cp-varios-municipios y aviso-de-uso-sepomex-distinto.

Correcciones:

• Caché del cliente: descuenta de max-age y de la ventana de stale-if-error la edad con la que llega la respuesta (Age), así que una respuesta que pasó por otra caché no se usa más tiempo del que permite la API. No guarda las respuestas no-cache, y una respuesta no-store o no-cache deja sin usar lo que había guardado de esa consulta, también para stale-if-error.
• El aviso transmision-poder-ejecutivo (SAT, 2030 y cada seis años) solo sale por el 1o. de octubre o el 1o. de diciembre que caen de lunes a viernes, y su texto nombra solo esos. En 2030 un cálculo que cruza el 1o. de diciembre, que es domingo, ya no lo trae, y el texto dice "no se descuenta el 1o. de octubre". codigoAviso reconoce el texto nuevo y el anterior.
• El detail del error por un parámetro desconocido da el nombre tal cual solo si tiene letras sin acento (A-Z, a-z), dígitos, _, . o -. Si no, lo da entre comillas y con lo invisible escapado (por ejemplo, ​): controles, caracteres de formato, separadores de línea y los que se ignoran por omisión (\p{Default_Ignorable_Code_Point}). La API, el cliente sin red y el servidor MCP dan el mismo texto.

mexicoapi-mcp 0.2.0

Cambios de comportamiento. Revisa tu configuración o tu uso si dependes de lo que nombran:

• validar_curp: la posición 17 (el diferenciador) solo acepta un dígito o una letra de la A a la J, como dice el Instructivo Normativo de la CURP (DOF 18-06-2018). Con una letra de la K a la Z la CURP es inválida, con el error estructura; antes se aceptaba cualquier letra.
• MEXICOAPI_BASE con http:// solo se acepta para localhost, 127.0.0.1 o [::1], con puerto o sin él. Con otro host el servidor no arranca (código 2, con un mensaje en stderr que pide https://).
• MEXICOAPI_SIN_RED acepta 1, true, yes, si u on para no usar la red y 0, false, no, off o vacía para consultar la API, sin distinguir mayúsculas. Otro valor hace que el servidor no arranque (código 2, con un mensaje en stderr). Antes solo 1 apagaba la red y cualquier otro valor la dejaba encendida sin avisar.

Otros cambios:

• Usa mexicoapi 0.2.0 (^0.2.0).
• validar_clabe: el resultado trae banco_revisado (siempre true), requerido en su outputSchema. La nota es la de la CLABE, sin el SAT, RENAPO ni el IMSS; cada validador tiene la suya.
• Cambia el texto de la advertencia de los datos del paquete que pueden no estar al día: "Respuesta con los datos del paquete mexicoapi, no de la API: pueden faltar publicaciones recientes." Antes nombraba MEXICOAPI_SIN_RED=1. Es la misma del cliente de mexicoapi y sale una sola vez.
• tipo_de_cambio_fix dice que las fechas son días de America/Mexico_City; con publicado en un día sin publicación, el error sugiere operacion.
• sumar_dias_habiles: con declaraciones_pagos, advertencia nueva si el resultado cae fuera de las vacaciones publicadas del SAT; con sat y general fuera de su cobertura, el error sugiere permitir_incompleto.
• Si la API responde con una redirección, con un cuerpo de más de 8 MB o con data de otro tipo, las herramientas de datos que caducan responden con los datos del paquete y la advertencia de respaldo. Antes la redirección se seguía y data de otro tipo daba un error de la herramienta.
• dias_inhabiles y sumar_dias_habiles con lft: los días anteriores al 2024-10-01 citan el texto del art. 74 vigente entonces, el de la reforma del DOF 17-01-2006, con su fecha_publicacion. Las fechas no cambian.
• Nuevas herramientas, sin red y con los datos del paquete: estados (las 32 entidades con su clave, nombre y abreviatura) y municipios_de_estado (todos los municipios y alcaldías de un estado, cada uno con su cvegeo y su nombre, con total y el estado; el estado va por cve_ent o por su nombre o abreviatura, sin distinguir mayúsculas ni acentos, también nombres de uso común como "Edomex", "Distrito Federal" o "Querétaro de Arteaga"; un nombre que no es de un solo estado da error, y "México" sin más también, porque puede ser el Estado de México o la Ciudad de México). Antes no había forma de listar los municipios de un estado y buscar_municipio con un texto corto daba solo parte de ellos.
• Nuevo tipo de error [sin-conexion], propio del servidor y no de la API: el cliente no llegó a la API (sin conexión o tiempo agotado) y los datos del paquete no bastan para responder. Antes era [error-interno] o, si el paquete no tenía el dato todavía, su tipo ([dato-no-disponible], [calendario-incompleto]), que no decía que la API no se pudo consultar; ahora el texto da primero la falla de conexión y después lo que dijo el paquete. Las respuestas definitivas del paquete ([no-encontrado], [parametro-invalido]) no cambian.
• Nuevo: avisos en el structuredContent de cada herramienta (y en datos de sumar_dias_habiles), requerido en su outputSchema: las mismas advertencias con un código estable, como en la API. El texto no cambia.
• dias_inhabiles y sumar_dias_habiles con sat: el aviso de la transmisión del Poder Ejecutivo (2030 y cada seis años) solo sale por el 1o. de octubre o el 1o. de diciembre que caen de lunes a viernes, y su texto nombra solo esos. En 2030 un cálculo que cruza el 1o. de diciembre, que es domingo, ya no lo trae.
• La caché de las respuestas de la API descuenta la edad con la que llegan (Age), no guarda las no-cache y deja de usar lo guardado de una consulta si la API responde no-store o no-cache, también como respaldo cuando la API falla.
• El error por un parámetro desconocido da el mismo texto que el detail de la API: el nombre tal cual si solo tiene letras sin acento (A-Z, a-z), dígitos, _, . o -, y si no, entre comillas y con lo invisible escapado, también lo que se ignora por omisión (\p{Default_Ignorable_Code_Point}). Como los argumentos de cada herramienta son fijos, casi nunca se ve.
• La fuente que citan los validadores es la página de mexicoapi en npm (https://www.npmjs.com/package/mexicoapi) en lugar del README de main, que puede describir otra versión.
• mcpName en el package.json y server.json en el repositorio, para el registro oficial de servidores MCP (io.github.Dagel4k/mexicoapi-mcp).