mail-mcp

La mayoría de los servidores MCP de correo solo hacen lecturas IMAP. Este lo hace todo: leer, buscar, enviar, responder, reenviar, operaciones masivas, Microsoft Graph API y Exchange Web Services — con OAuth2 real, soporte multi-cuenta y multi-proveedor. Escrito en Rust por velocidad y seguridad.

Novedades en v0.4.10

Versión comunitaria — los tres cambios provinieron de colaboradores externos. ¡Gracias!

• Compatibilidad con IMAP de NetEase (126.com / 163.com / yeah.net) por @pep-27 en #21. Los servidores de NetEase rechazan el acceso al buzón de clientes que no se identifican. mail-mcp ahora envía el comando ID de RFC 2971 después de la autenticación siempre que el servidor anuncie la capacidad ID. Incluye pruebas de regresión con servidor simulado y documentación de configuración de NetEase en docs/account-setup.md.

• MAIL_SMTP_<ID>_FROM_EMAIL — anulación de la dirección de remitente por @arwack en #19. Para buzones compartidos/de grupo donde SMTP se autentica con una cuenta personal pero la dirección From debe ser la del grupo. Se aplica a enviar, responder (incluida la detección de la propia dirección en responder a todos) y reenviar; recurre a _USER cuando no se establece.

• Las copias de correo enviado ahora se marcan como \Seen por @ray-of-darkness en #9. Las copias que el MCP añade a la carpeta de Enviados tras el envío SMTP ya no aparecen como no leídas.

Related MCP server: outlook-mcp-server

Novedades en v0.4.9

• Nueva herramienta imap_get_attachment: descarga un único adjunto al disco. Hasta ahora, las únicas formas de acceder a los bytes de un adjunto eran imap_get_message (que devuelve metadatos del adjunto y opcionalmente texto PDF extraído, nunca el binario) e imap_get_message_raw (limitado a 1 MB y codificado en base64 en la respuesta). Un correo de 7 MB con imágenes de rayos X no se podía recuperar en absoluto: superaba el límite, y volcarlo en la respuesta habría reventado igualmente el contexto del modelo.

• Cómo funciona: llama a imap_get_attachment con message_id más un selector: ya sea part_id (el valor que imap_get_message informa para cada adjunto) o filename. El servidor obtiene el mensaje completo (sin límite de tamaño en el lado del servidor), extrae y decodifica solo esa parte, y la escribe en el disco, devolviendo { file_path, filename, content_type, part_id, size_bytes }. El binario nunca entra en la respuesta, por lo que el contexto se mantiene pequeño. La ruta guardada se alimenta directamente a un lector local (por ejemplo, una herramienta de descripción de imágenes o un lector de PDF).

• Dónde se guardan los archivos: el argumento output_dir si se proporciona; si no, la variable de entorno MAIL_ATTACHMENT_DOWNLOAD_DIR; si no, el directorio temporal del sistema. Los nombres de archivo se sanean (solo el nombre base, se eliminan los caracteres de control) para evitar el path traversal, y se prefijan con el UID del mensaje y el id de la parte para evitar colisiones.

• Base64 en línea opcional: establece include_base64: true para obtener también los bytes en la respuesta, pero solo cuando el adjunto tenga como máximo max_inline_bytes (256 KiB por defecto). Desactivado por defecto.

Novedades en v0.4.8

• SAVE_SENT ahora es por cuenta con un valor predeterminado según el proveedor. Anteriormente, guardar una copia del correo saliente en la carpeta de Enviados mediante IMAP APPEND estaba controlado por un único flag global, MAIL_SMTP_SAVE_SENT. El problema: los proveedores que ya guardan el correo enviado en el servidor (Gmail, Zoho) terminaban con dos copias idénticas en Enviados, mientras que un servidor SMTP genérico u Office 365 (que no guardan automáticamente en el envío SMTP) perdían la copia por completo cuando el flag era false.

• Valor predeterminado según el proveedor (cuando no hay nada configurado):

  • Gmail (smtp.gmail.com): guarda en el servidor y deduplica por Message-ID → el MCP no añade (false).

  • Zoho (smtp.zoho.com): guarda en el servidor pero no deduplica → el MCP no añade (false), evitando el duplicado.

  • Office 365 / SMTP genérico: no guardan automáticamente en el envío SMTP → el MCP sí añade (true), o la copia enviada se perdería.

• Anulación por cuenta: MAIL_SMTP_<ID>_SAVE_SENT=true|false tiene prioridad sobre todo. El global MAIL_SMTP_SAVE_SENT sigue funcionando como una anulación general (gana al valor predeterminado del proveedor, pero pierde frente a la anulación por cuenta).

• Precedencia: por cuenta → global → valor predeterminado según el proveedor.

Novedades en v0.4.7

• Corrección crítica: graph_send_message descartaba silenciosamente los adjuntos en respuestas enhebradas. Cuando se llamaba con in_reply_to + attachments, el flujo createReply → PATCH → send incluía los adjuntos en el PATCH contra /me/messages/{id}. Microsoft Graph trata Message.attachments como una propiedad de navegación y descarta silenciosamente el campo en PATCH (respuesta 2xx, sin error), por lo que el mensaje salía como text/html de una sola parte sin archivo. El MCP devolvía status: ok y el llamante asumía éxito. Pérdida de datos invisible.

• La corrección: en send_via_reply(), los adjuntos ahora se suben uno a uno a POST /me/messages/{draft_id}/attachments entre el PATCH y el envío. Los archivos < 3 MB van en línea (JSON con contentBytes en base64); los archivos ≥ 3 MB usan createUploadSession con PUTs fragmentados de 4 MB. El campo attachments se eliminó de la estructura PatchDraftRequest para que la regresión no pueda reintroducirse con una edición de tipo correcto.

• Sin cambios en los flujos que ya funcionaban. send_via_sendmail (mensajes nuevos sin in_reply_to) usa POST /me/sendMail con attachments en línea en el JSON: Graph SÍ acepta el campo en ese endpoint y nunca lo descartó. Esa ruta no se ha tocado.

• Prueba de regresión añadida: patch_draft_request_never_serializes_attachments falla si alguien vuelve a añadir el campo a la estructura.

• Referencia: BUG_GRAPH_ATTACHMENTS.md en la raíz del repositorio documenta la reproducción completa, la causa raíz y la evidencia empírica detrás de la corrección.

Novedades en v0.4.6

• Aplicación en el servidor de la REGLA DURA #1. Tres versiones de refuerzo solo con prompt (v0.4.3 → v0.4.4 → v0.4.5) aún dejaban que los LLM filtraran ocasionalmente el marcado literal </body_text><parameter name="body_html"> en la bandeja de entrada del destinatario. v0.4.6 añade un validador real que rechaza la llamada a la herramienta antes de cualquier intento SMTP / Graph / EWS si body_text o body_html contienen sintaxis de envoltura de llamada a herramienta. La comprobación está conectada a las 5 rutas de envío (smtp_send_message, smtp_reply_message, smtp_forward_message, graph_send_message, ews_send_message).

• Los marcadores prohibidos no distinguen mayúsculas de minúsculas y están estrictamente acotados: solo las pseudoetiquetas que no tienen uso legítimo en la correspondencia humana: <body_text>, </body_text>, <body_html>, </body_html>, <function_calls>, </function_calls>, <invoke name=, </invoke>, y <parameter name="body_*">. El contenido técnico genérico que mencione <parameter> para un esquema XML o <invoke> en un ejemplo de código sigue pasando.

• Redacción de la REGLA DURA #1 actualizada para anunciar el rechazo en el servidor, de modo que el LLM sepa que es un contrato duro, no una sugerencia que pueda ignorar.

• Sin cambios disruptivos para los llamantes limpios: los mensajes bien formados se envían exactamente igual que antes.

Novedades en v0.4.5

• serverInfo ahora informa name="mail-mcp" + la version de la crate (el framework anteriormente devolvía su propio rmcp 0.16.0, que nunca cambia entre versiones). Útil para verificar la versión activa con /mcp, y para que cualquier caché del lado del cliente claveada por (servidor, versión) se invalide en cada incremento.

• Instrucciones MCP reorganizadas: las 3 reglas críticas anti-concatenación (que en v0.4.3 y v0.4.4 estaban al final del bloque y podían perderse por truncamiento / atención diluida) ahora aparecen como REGLA DURA #1, #2, #3 al PRINCIPIO, justo después del título. Consolidadas en 3 párrafos cortos (anteriormente 3 secciones largas, ~1500 caracteres en total).

• Sin cambios funcionales en el servidor. Mismo SMTP/IMAP/EWS/Graph, mismo conjunto de herramientas, mismo comportamiento. Solo cambió el texto expuesto al cliente.

Importante para que estas reglas surtan efecto

Los clientes que reanudan una sesión con claude --continue (o /resume) NO actualizan el system_prompt del MCP: conservan el del primer handshake de esa sesión. Si tu sesión es anterior a v0.4.5, las reglas no llegarán a tu contexto aunque el binario en disco esté actualizado. Para recibirlas, inicia una sesión NUEVA en el proyecto (no --continue).

Novedades en v0.4.4

• Regla de higiene de vista previa en las instructions del MCP: cuando el LLM muestra al usuario la vista previa del correo antes de enviarlo, debe renderizar UNA versión limpia del cuerpo (viñetas estilo markdown, negritas, enlaces como texto + URL) e indicar que el mensaje irá multiparte, pero NO debe volcar el código HTML crudo (<p>, <strong>, <a href>...) en la vista previa. Dos razones:

  1. El revisor humano quiere leer el mensaje, no auditar el marcado: mostrar el HTML es ruido.

  2. Exhibir tanto la cadena de texto plano COMO la cadena HTML una al lado de la otra en la vista previa es exactamente el contexto que históricamente ha llevado a los LLM a concatenarlas en la llamada a la herramienta final (el bug que documentó v0.4.3). Ocultar el código HTML de la vista previa elimina la tentación.

  Complementa la regla LA VISTA PREVIA NO ES IGUAL A LA LLAMADA A LA HERRAMIENTA introducida en v0.4.3.

Novedades en v0.4.3

• Orientación en el servidor contra llamadas a herramientas malformadas. El bloque instructions del MCP ahora le dice explícitamente al LLM llamante que body_text y body_html son DOS CAMPOS JSON SEPARADOS y que NUNCA deben concatenarse. La redacción anterior ("envía TANTO body_text AND body_html") era ambigua y algunos LLM la interpretaron como "concatena ambos con pseudoetiquetas <body_text>...</body_html> dentro de una sola cadena body_text". Cuando eso ocurre, el destinatario ve contenido duplicado y distorsionado, Y cualquier sesión posterior de Claude que abra la copia guardada a través de este MCP recibe un bloqueo de Política de Uso (el <invoke>...</invoke> filtrado parece un intento de inyección de prompt a los filtros de seguridad). La nueva instrucción muestra un ejemplo CORRECTO vs INCORRECTO y prohíbe las pseudoetiquetas / sintaxis de envoltura de llamada a herramienta dentro de los campos de correo.

Novedades en v0.4.2

• Pipeline de publicación corregido: el trabajo publish-npm del flujo de trabajo de publicación en CI se ha deshabilitado. Se heredó del fork upstream e intentaba publicar en @bradsjm/mail-imap-mcp-rs, un ámbito que esta organización no posee: cada lanzamiento fallaba con 404 en ese paso. Consulta "Releasing" más abajo para ver la explicación completa y cómo volver a habilitar la publicación npm si es necesario.

• Publicación automática al hacer push de una etiqueta: .github/workflows/release.yml ahora se activa con push: tags: ['v*'], así que etiquetar vX.Y.Z y hacer push es todo lo necesario para lanzar una versión. workflow_dispatch se mantiene como vía manual de escape.

• Limpieza: se eliminó el flujo de trabajo colgante init-npm-placeholder.yml (que también hacía referencia al ámbito npm del fork).

• Documentación: el README incorpora una sección "Releasing" que documenta el nuevo flujo y la decisión sobre npm.

Novedades en v0.4.1

• Corrección: save_to_sent_folder ahora archiva los bytes RFC822 exactos que se enviaron (mediante lettre.formatted()), en lugar de un stub de solo texto hecho a mano. La copia en la carpeta de enviados conserva el cuerpo HTML, la estructura multipart/alternative y el asunto codificado según RFC 2047: se acabaron los ??? donde antes había acentos, y el HTML ya no se descarta silenciosamente.

• Mejora: detección localizada de la carpeta de enviados: Enviado[s], Elementos enviados, Enviadas, Itens enviados, Envoyés, Éléments envoyés, Gesendet, Posta inviata, Verzonden, Wysłane, además de variantes anidadas. Antes solo se reconocían nombres en inglés, por lo que las cuentas IMAP de Zoho o localizadas caían en una carpeta "Sent" inexistente.

• Mejora: smtp_forward_message acepta body_html (antes estaba fijado a solo texto plano).

• Mejora: el envío por EWS incorpora bcc, in_reply_to, references (mediante <t:InternetMessageHeaders>), además de validación completa de destinatarios y longitud del asunto: ahora está a la par con las rutas de envío por SMTP y Graph.

• Mejora: los fallbacks de encadenado de Graph API ahora registran. WARN cuando falla la llamada HTTP de búsqueda del mensaje (límite de tasa, 5xx, permisos) para que los operadores vean que el encadenado se degradó por un error real; DEBUG cuando el mensaje original legítimamente no se encuentra.

• Refactorización: el análisis XML de EWS migró de la coincidencia de subcadenas a quick-xml. Corrige un error latente de colisión de espacios de nombres (<soap:Body> vs <t:Body>), decodifica correctamente las entidades XML y CDATA, y maneja valores de atributos que contienen = (común en IDs de elementos EWS similares a base64).

• Limpieza: cero advertencias en cargo build --release.

• Pruebas: 64 (antes 47).

Por qué este proyecto

Matriz de características

EWS es la forma más sencilla de añadir cuentas de Microsoft: un único token OAuth2 para leer y enviar. Funciona incluso en inquilinos que bloquean Graph API e IMAP.

Inicio rápido — Deja que Claude Code lo haga

Copia y pega este prompt en Claude Code y él instalará, compilará y configurará todo por ti:

Install and configure the mail-mcp MCP server from https://github.com/tecnologicachile/mail-mcp

1. Clone the repo, build with cargo build --release
2. Add the MCP server to .claude.json with the binary path
3. For Microsoft accounts: use EWS (simplest) — run device code flow with
   client_id d3590ed6-52b3-4102-aeff-aad2292ab01c and scope
   https://outlook.office365.com/EWS.AccessAsUser.All offline_access
   Then configure MAIL_EWS_<ID>_USER and MAIL_EWS_<ID>_REFRESH_TOKEN
4. For Gmail: configure MAIL_IMAP + MAIL_SMTP with App Password from
   https://myaccount.google.com/apppasswords
5. For Zoho: configure MAIL_IMAP + MAIL_SMTP with standard password
6. Enable write/send: MAIL_IMAP_WRITE_ENABLED=true, MAIL_SMTP_WRITE_ENABLED=true

My email accounts to configure:
- <your-email@example.com>

Reemplaza la última línea con tu(s) correo(s) electrónico(s). Claude Code te guiará en cada paso, incluido el flujo de código de dispositivo OAuth2 para cuentas de Microsoft.

Configuración manual (2 minutos)

git clone https://github.com/tecnologicachile/mail-mcp.git
cd mail-mcp
cargo build --release

Añade esto a la configuración de tu cliente MCP (Claude Code, Cursor, etc.):

{
  "mcpServers": {
    "mail": {
      "command": "./target/release/mail-mcp",
      "env": {
        "MAIL_IMAP_DEFAULT_HOST": "imap.gmail.com",
        "MAIL_IMAP_DEFAULT_USER": "you@gmail.com",
        "MAIL_IMAP_DEFAULT_PASS": "your-app-password",
        "MAIL_SMTP_DEFAULT_HOST": "smtp.gmail.com",
        "MAIL_SMTP_DEFAULT_PORT": "587",
        "MAIL_SMTP_DEFAULT_USER": "you@gmail.com",
        "MAIL_SMTP_DEFAULT_PASS": "your-app-password",
        "MAIL_SMTP_DEFAULT_SECURE": "starttls",
        "MAIL_IMAP_WRITE_ENABLED": "true",
        "MAIL_SMTP_WRITE_ENABLED": "true"
      }
    }
  }
}

Eso es todo. Tu agente de IA ya puede leer, buscar, enviar, responder y gestionar correos electrónicos.

¿Tienes una cuenta de Microsoft? Usa Graph API

Microsoft bloquea SMTP en cuentas personales. Usa Graph API en su lugar:

{
  "env": {
    "MAIL_IMAP_DEFAULT_HOST": "outlook.office365.com",
    "MAIL_IMAP_DEFAULT_USER": "you@hotmail.com",
    "MAIL_IMAP_DEFAULT_PASS": "your-app-password",
    "MAIL_OAUTH2_DEFAULT_PROVIDER": "microsoft",
    "MAIL_OAUTH2_DEFAULT_CLIENT_ID": "9e5f94bc-e8a4-4e73-b8be-63364c29d753",
    "MAIL_OAUTH2_DEFAULT_CLIENT_SECRET": "none",
    "MAIL_OAUTH2_DEFAULT_REFRESH_TOKEN": "<your-token>"
  }
}

Obtén tu token en 1 minuto con el flujo de código de dispositivo. Consulta la Guía de configuración de la cuenta.

31 herramientas MCP

Lectura (9 herramientas)

Escritura (11 herramientas)

Envío (5 herramientas)

EWS — Exchange Web Services (3 herramientas)

Adjuntos

Envía archivos con cualquier herramienta de envío. Dos modos:

// Large files — MCP reads from disk (recommended)
"attachments": [{"file_path": "/path/to/report.pdf"}]

// Small files — inline base64
"attachments": [{"filename": "note.txt", "content_type": "text/plain", "content_base64": "SGVsbG8="}]

El nombre de archivo y el tipo MIME se detectan automáticamente a partir de la ruta del archivo. Responde con include_original_attachments: true para reenviar los adjuntos originales.

Descargar un adjunto de un mensaje recibido: usa imap_get_attachment con el message_id y un part_id (de imap_get_message) o filename. Escribe el archivo decodificado en el disco y devuelve la ruta: sin límite de tamaño, y el binario no aparece en la respuesta. Establece el directorio de descarga predeterminado con MAIL_ATTACHMENT_DOWNLOAD_DIR (si no, usa el directorio temporal del sistema) o pasa output_dir en cada llamada.

Operaciones masivas (2 herramientas)

Asistente de configuración (1 herramienta)

Multicuenta

Configura tantas cuentas como necesites:

# Gmail
MAIL_IMAP_GMAIL_HOST=imap.gmail.com
MAIL_IMAP_GMAIL_USER=me@gmail.com
MAIL_IMAP_GMAIL_PASS=app-password

# Microsoft 365
MAIL_IMAP_WORK_HOST=outlook.office365.com
MAIL_IMAP_WORK_USER=me@company.com
MAIL_OAUTH2_WORK_PROVIDER=microsoft
MAIL_OAUTH2_WORK_CLIENT_ID=your-client-id
MAIL_OAUTH2_WORK_CLIENT_SECRET=none
MAIL_OAUTH2_WORK_REFRESH_TOKEN=your-token

# Zoho
MAIL_IMAP_DEFAULT_HOST=imap.zoho.com
MAIL_IMAP_DEFAULT_USER=info@mydomain.com
MAIL_IMAP_DEFAULT_PASS=password
MAIL_SMTP_DEFAULT_HOST=smtp.zoho.com
MAIL_SMTP_DEFAULT_USER=info@mydomain.com
MAIL_SMTP_DEFAULT_PASS=password
MAIL_SMTP_DEFAULT_SECURE=starttls

Usa account_id en las llamadas a las herramientas: "account_id": "gmail", "account_id": "work", "account_id": "default".

Seguridad

• TLS obligatorio en todas las conexiones (excepto proxies de localhost)

• Contraseñas en SecretString: nunca se registran ni se devuelven en las respuestas

• Operaciones de escritura restringidas: requieren MAIL_IMAP_WRITE_ENABLED=true explícito

• Operaciones de envío restringidas: requieren MAIL_SMTP_WRITE_ENABLED=true explícito

• Confirmación de eliminación: requiere confirm: true

• HTML saneado con ammonia (previene XSS)

• Salidas limitadas: el texto del cuerpo, el HTML y los adjuntos se truncan según límites configurables

• Tokens OAuth2 almacenados en caché con un margen de renovación de 10 minutos

• Sin secretos en las respuestas: las credenciales nunca se exponen a través de las herramientas MCP

Referencia de configuración

IMAP (por cuenta)

SMTP (por cuenta)

Hoja de ruta

• Operaciones de lectura IMAP (búsqueda, obtención, análisis)

• Operaciones de escritura IMAP (copiar, mover, eliminar, banderas)

• Operaciones masivas IMAP (hasta 500 por llamada)

• Paginación basada en cursor con TTL

• Envío, respuesta y reenvío SMTP

• Microsoft Graph API (sendMail)

• OAuth2 XOAUTH2 (Google + Microsoft)

• Tokens de Graph API separados para empresas

• Multicuenta mediante variables de entorno

• Extracción de texto PDF de los adjuntos

• Saneamiento de HTML (ammonia)

• Documentación de configuración del proveedor con enlaces directos

• Envío de adjuntos (SMTP/Graph)

• Responder con los adjuntos originales

• Saneamiento de CDATA (corrección de error de Zoho)

• Protocolo de confirmación de correo (vista previa antes de enviar)

• Instrucciones optimizadas en tokens (reducción del 75 %)

• Herramienta de guía de configuración bajo demanda

• EWS (Exchange Web Services) — un solo token para leer y enviar en Microsoft

• EWS con Microsoft Office Client ID (funciona en inquilinos restringidos)

• Subprocesos de Graph API — flujo createReply para un subprocesado de conversación correcto

• Guía de formato HTML — el LLM prefiere multiparte (texto + HTML) para correos humanos

• El archivado en la carpeta de Enviados conserva el MIME completo — copia idéntica byte a byte de lo que recibió el destinatario (v0.4.1)

• Detección localizada de la carpeta de Enviados — español / portugués / francés / alemán / italiano / neerlandés / polaco (v0.4.1)

• Paridad de funciones de EWS con SMTP/Graph — CCO, encabezados de hilo, validación de destinatarios (v0.4.1)

• Analizador XML de EWS mediante quick-xml — manejo correcto de entidades/CDATA/espacios de nombres (v0.4.1)

Siguiente — Caché local con búsqueda instantánea

• Caché local de correo SQLite + FTS5 — búsquedas instantáneas (<10 ms frente a 3-10 s)

• Sincronización incremental — UIDVALIDITY + sincronización delta del último UID

• Agrupación de conexiones — sesiones IMAP persistentes por cuenta

• Búsqueda entre cuentas — buscar en todas las cuentas a la vez

• Estadísticas de correo — recuentos, remitentes principales, actividad por fecha

Futuro

• Imagen de Docker

• Distribución npm/npx

• Gestión de borradores

• Búsqueda de contactos

• IMAP IDLE (notificaciones en tiempo real)

• Sitio de documentación alojado

Documentación

Desarrollo

cargo test              # 64 unit + integration tests
cargo fmt -- --check    # formatting
cargo clippy --all-targets -- -D warnings  # linting

Consulta AGENTS.md para las directrices de contribución.

Publicación

Las publicaciones se automatizan mediante cargo-dist. Para lanzar una nueva versión:

1. Incrementa version = "X.Y.Z" en Cargo.toml (el flujo de trabajo de publicación exige que coincida con la etiqueta enviada).

2. Haz commit del incremento y de las notas de la versión en main.

3. Crea la etiqueta y haz push:

   git tag vX.Y.Z
   git push origin main --tags

4. El desencadenante push: tags: ['v*'] en .github/workflows/release.yml compila binarios para Linux / macOS (Intel + Apple Silicon) / Windows, genera scripts de instalación (.sh, .ps1), crea la GitHub Release y adjunta todos los artefactos con sumas de verificación SHA256.

5. Si algo falla, puedes volver a ejecutar el flujo de trabajo manualmente desde la pestaña Actions (el desencadenante workflow_dispatch se conserva como vía de escape).

La publicación en npm está deshabilitada intencionadamente. El fork upstream estaba configurado para publicar como @bradsjm/mail-imap-mcp-rs, un ámbito que esta organización no posee, lo que provocaba que cada publicación diera 404 en npm publish. El tarball de npm se sigue generando y adjuntando a cada GitHub Release para que los usuarios puedan instalarlo manualmente mediante npm install ./mail-mcp-npm-package.tar.gz. Para habilitar la publicación en el registro npm para este fork: crea una organización npm (p. ej., @tecnologicachile), configura Trusted Publishing en npmjs.com apuntando a este repositorio, establece publish-jobs = ["npm"] en dist-workspace.toml y ejecuta dist generate --allow-dirty para restaurar el trabajo publish-npm en release.yml.

Contribuciones

¡Las contribuciones son bienvenidas! Consulta los issues para encontrar buenos primeros issues.

Licencia

Licencia MIT — consulta LICENSE para más detalles.