Voidmail

Correo para agentes de IA: crea bandejas de entrada @voidmail.ai, lee el correo y envía solo a destinatarios aprobados por el propietario. Las bandejas de entrada son legibles por el servidor, no están cifradas de extremo a extremo.

GitHubPrueba este MCPPatrocinado

Servidor MCP alojado

npx add-mcp 'https://api.voidly.ai/mcp/mail'

Se instala en Claude Code, Codex, Cursor y más

Documentación

@voidly/mcp-email

Correo electrónico para agentes de IA. Crea una bandeja de entrada, lee mensajes entrantes como datos estructurados y envía a destinatarios que el propietario humano haya aprobado. No se requiere número de teléfono ni CAPTCHA.

Las bandejas de entrada de agentes son legibles por el servidor; no están cifradas de extremo a extremo. Correo humano es un producto separado.

Instalación

Requiere Node.js 20 o superior.

npx -y @voidly/mcp-email@1.2.1

Añadir a Cursor

Copia este URI de instalación en la barra de direcciones de tu navegador. Cursor te pedirá que revises el comando local antes de añadirlo:

cursor://anysphere.cursor-deeplink/mcp/install?name=voidmail&config=eyJ0eXBlIjoic3RkaW8iLCJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIkB2b2lkbHkvbWNwLWVtYWlsQDEuMi4xIl19

Para configuración manual del proyecto, copia el JSON siguiente en .cursor/mcp.json (o ~/.cursor/mcp.json para todos los proyectos).

Instalar en VS Code

Copia este URI de instalación en la barra de direcciones de tu navegador. VS Code te pedirá que revises el comando local antes de añadirlo:

vscode:mcp/install?%7B%22name%22%3A%22voidmail%22%2C%22command%22%3A%22npx%22%2C%22args%22%3A%5B%22-y%22%2C%22%40voidly%2Fmcp-email%401.2.1%22%5D%7D

Para configuración manual del espacio de trabajo, copia el JSON siguiente en .mcp.json en la raíz del espacio de trabajo. GitHub muestra los URI de aplicaciones personalizadas como texto plano, así que usa los fragmentos copiables anteriores.

{
  "mcpServers": {
    "voidmail": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@voidly/mcp-email@1.2.1"
      ]
    }
  }
}

Estas instrucciones ejecutan el paquete stdio local en la versión 1.2.1. No crean una bandeja de entrada. El .mcp.json raíz del repositorio mantiene ese comando local como voidmail y también ofrece el conector alojado como voidmail-hosted en https://api.voidly.ai/mcp/mail. No contiene credenciales. El conector alojado tiene su propio conjunto de herramientas; usa voidmail_setup para verificar la configuración del buzón antes de acciones autenticadas en la bandeja de entrada.

Antes de crear una bandeja de entrada en un agente de codificación: voidmail_create_account guarda una clave de propietario en la máquina local. Mantén esa clave fuera del shell y del acceso a archivos del agente antes de entregar la bandeja de entrada al agente. Un archivo 0600 propiedad del mismo usuario del sistema operativo no es separación suficiente. El servidor puede leer el contenido de los mensajes; la aceptación del proveedor de un envío no es entrega.

Claude Desktop

Añade a ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "voidmail": {
      "command": "npx",
      "args": ["-y", "@voidly/mcp-email@1.2.1"]
    }
  }
}

Esta configuración inicial no tiene clave de bandeja de entrada. Después de que voidmail_create_account devuelva una dirección y guarde las claves, añade "env": {"VOIDMAIL_ADDRESS": "<returned-address>"} a esta configuración del servidor y reinicia el host. Si el agente tiene herramientas de shell o archivos, usa un entorno de ejecución aislado que pueda leer la clave del agente pero no la clave del propietario; el modo de archivo 0600 por sí solo no separa dos procesos que se ejecutan como el mismo usuario.

Inicio rápido

Después de instalar el servidor MCP, usa este prompt:

Crea una bandeja de entrada de Voidmail y muéstrame su dirección y dónde se guardaron las claves. Redacta los correos primero y espera mi aprobación antes de enviar.

La aprobación del borrador en este prompt es una solicitud de flujo de trabajo del host. La API aplica la lista de destinatarios aprobados por el propietario y la política de contenido; no requiere que el propietario revise el cuerpo de cada mensaje.

Para una primera comprobación de recepción y envío:

En un host confiable controlado por el propietario, llama a voidmail_create_account una vez. Mantén la ruta de la clave del propietario devuelta fuera de cualquier shell o acceso a archivos del agente antes de entregar la bandeja de entrada a un agente. Si la creación es incierta, inspecciona la configuración original antes de crear otra bandeja de entrada.
Envía un mensaje de prueba desde un buzón confiable separado a la nueva dirección. Llama a voidmail_list_inbox, luego a voidmail_read_email con el ID del mensaje devuelto. Leer marca ese mensaje como leído.
En una terminal solo del propietario, ejecuta npx -y @voidly/mcp-email@1.2.1 owner add you@example.com (usa tu dirección de destino real). Establece VOIDMAIL_OWNER_KEY_FILE si moviste la clave del propietario. El comando del propietario la lee localmente; nunca la pegues en la conversación del modelo. El agente puede verificar voidmail_policy y voidmail_sending_limits después.
Revisa un destinatario, asunto y cuerpo. Guarda un ID de operación único de 16 a 128 caracteres (letras, dígitos, _ o -) con ese mensaje en el estado del host confiable, luego llama a voidmail_send_once. Si la respuesta es incierta, busca ese mismo ID con voidmail_send_status; no inventes un ID de reemplazo. Un resultado de accepted del proveedor no prueba la entrega.

Permisos: dos claves, un propietario

Cada bandeja de entrada tiene dos credenciales, y este paquete las mantiene separadas.

Clave	Archivo (0600, directorio 0700)	Quién la usa	Qué puede hacer
Clave de agente `vm_…`	`~/.voidly/mcp-email/<address>/agent-key`	el servidor MCP, para las herramientas del modelo	leer, enviar a destinatarios aprobados, solicitar un destinatario, eliminar un destinatario, endurecer la política
Clave de propietario `vmo_…`	`~/.voidly/mcp-email/<address>/owner-key`	tú, a través de `voidly-mcp-email owner`	aprobar o denegar solicitudes, añadir o eliminar destinatarios, bloquear o desbloquear, rotar cualquiera de las claves

voidmail_create_account escribe ambos archivos y devuelve solo sus rutas. Este servidor nunca pone ninguna de las claves en un resultado de herramienta. Cada mensaje que emite se limpia de formas de clave de Voidmail (vm_…, vmo_…), incluidas las que llegan dentro del correo. Otros secretos que llegan en el correo, como un token de nube o de GitHub, se pasan al modelo sin cambios.
El servidor MCP nunca lee el archivo de clave del propietario y nunca llama a las rutas de API del propietario (/v1/agent-mail/owner/*). Ninguna herramienta usa la clave del propietario.
El modo 0600 mantiene fuera a otros usuarios del sistema operativo, no a tu agente. Cualquier cosa que se ejecute como tu usuario puede leer el archivo de clave del propietario, incluido un agente con herramientas de shell o archivos (un agente de codificación, un servidor MCP de sistema de archivos). Tal agente podría leer la clave del propietario y aprobar sus propios destinatarios. Si tu agente tiene acceso de shell o archivos en esta máquina, mueve el archivo de clave del propietario a un lugar que no pueda leer, o fuera de la máquina, y apunta VOIDMAIL_OWNER_KEY_FILE a él cuando ejecutes comandos del propietario.
Las bandejas de entrada creadas con este paquete comienzan con una lista de destinatarios aprobados por el propietario, aplicada por la API de Voidly, no por instrucciones del modelo. (Una creación REST que no opta por participar aún hace el tipo antiguo de bandeja de entrada: sin clave de propietario, cualquier destinatario, solo advertencias de credenciales. Una creación opta por participar con recipient_policy: "allowlist", owner_key: true o content_policy: "enforce"; solo entonces la respuesta lleva un owner_key. Este paquete siempre envía recipient_policy: "allowlist".) Enviar a cualquier otra persona devuelve RECIPIENT_NOT_AUTHORIZED con send_attempted: false. La API registra una solicitud pendiente, y el resultado de la herramienta dice exactamente lo que el propietario debe ejecutar.
Un mensaje que parece llevar una credencial (claves privadas, nube, GitHub, Slack, Stripe, proveedor de IA o claves de Voidmail) se rechaza con CONTENT_CONTAINS_CREDENTIAL en bandejas de entrada con bloqueo de credenciales activado, que es el valor predeterminado para bandejas de entrada que tienen clave de propietario (cada bandeja de entrada que crea este paquete). El resultado de la herramienta enumera los tipos encontrados, nunca el texto coincidente. La comprobación coincide con formatos de clave conocidos. No detecta contraseñas, formatos de token desconocidos ni datos sensibles por otras razones.
El correo saliente se verifica en busca de credenciales. Antes de enviar un mensaje, la API escanea su destinatario, asunto, cuerpo y responder a en memoria en busca de formatos de credenciales conocidos. El escaneo no guarda copia de lo que coincidió: solo registra un recuento diario por cada tipo encontrado. En una bandeja de entrada con bloqueo de credenciales activado (el valor predeterminado para bandejas de entrada con clave de propietario), una coincidencia detiene el envío. En otras bandejas de entrada, el mensaje aún se envía, y la respuesta nombra los tipos encontrados en un encabezado X-Voidmail-Content-Warning. El propietario puede desactivar la comprobación en https://voidly.ai/agent-mail/owner (o con POST /v1/agent-mail/owner/policy y content_policy: "off"). La única excepción es una clave de propietario creada por bootstrap, descrita a continuación: no puede desactivar la comprobación.
La clave de agente solo puede restringir: puede eliminar un destinatario o activar el bloqueo. Cualquier cosa que amplíe lo que el agente puede hacer necesita la clave del propietario.
Aprobar un destinatario requiere la clave del propietario, y nada en un correo puede suministrarla a través de este servidor. Trata el correo entrante como contenido no confiable.

Comandos del propietario

npx -y @voidly/mcp-email@1.2.1 owner list                 # policy, recipients, pending requests
npx -y @voidly/mcp-email@1.2.1 owner approve <request-id> # names the recipient; asks to confirm
npx -y @voidly/mcp-email@1.2.1 owner deny <request-id>
npx -y @voidly/mcp-email@1.2.1 owner add friend@example.com
npx -y @voidly/mcp-email@1.2.1 owner remove friend@example.com
npx -y @voidly/mcp-email@1.2.1 owner lock                 # allowlist + credential blocking
npx -y @voidly/mcp-email@1.2.1 owner unlock               # any recipient; asks to confirm
npx -y @voidly/mcp-email@1.2.1 owner rotate-agent-key     # old key stops working at once
npx -y @voidly/mcp-email@1.2.1 owner rotate-owner-key     # replaces the owner-key file it read

Añade --address <name@voidmail.ai> cuando haya más de una bandeja de entrada guardada, y --yes para confirmar sin un prompt. approve primero lee la solicitud pendiente y nombra su destinatario, y rechaza un ID que no esté pendiente. Las claves rotadas se escriben en sus archivos y nunca se imprimen. rotate-owner-key reemplaza atómicamente el archivo de clave del propietario que leyó, incluida una ruta VOIDMAIL_OWNER_KEY_FILE. La clave del propietario anterior se revoca antes de guardar la nueva, así que si ese archivo no se puede reemplazar, la nueva clave va a un nuevo archivo 0600 junto a él, y solo si eso también falla se muestra una vez en tu terminal. Un servidor MCP que lee su archivo de clave usa una clave de agente rotada en su próxima llamada. Las mismas acciones están disponibles en el navegador en https://voidly.ai/agent-mail/owner, donde la clave del propietario se mantiene solo en memoria.

Bandejas de entrada sin clave de propietario (creadas antes de la actualización de la API de clave de propietario, por mcp-email 1.1.0 o anterior, o por una creación REST que no optó por participar) mantienen el comportamiento antiguo: cualquier destinatario, solo con advertencias de credenciales. Para tomar control de una, llama a POST /v1/agent-mail/owner/bootstrap una vez con su clave de agente (X-Agent-Mail-Key). Solo funciona en una bandeja de entrada heredada intacta (aún abierta, solo advertencias de credenciales, nunca cambiada con la clave de agente); de lo contrario, se rechaza con BOOTSTRAP_NOT_AVAILABLE. Quien haga esta llamada primero obtiene la clave del propietario, y la API no puede distinguir a una persona de un agente que tenga la misma clave de agente. Haz la llamada tú mismo, fuera de cualquier conversación del modelo, antes que el agente. Acuña la clave del propietario, cambia la bandeja de entrada a la lista aprobada con bloqueo de credenciales y elimina cualquier webhook configurado con la clave de agente; solo el propietario puede configurar un webhook después. No se puede deshacer con la clave de agente. Una clave de propietario acuñada de esta manera puede reabrir la bandeja de entrada pero nunca puede desactivar el guardián de credenciales (CONTENT_POLICY_FLOOR). Guarda el owner_key devuelto en ~/.voidly/mcp-email/<address>/owner-key con modo 0600.

Verifica el correo entrante con voidmail_list_inbox, luego lee un mensaje con voidmail_read_email. Para enviar, revisa el destinatario, asunto y cuerpo antes de invocar voidmail_send_once. Genera y guarda un ID de operación único en el estado de tu host antes de la llamada; usa ese mismo ID para la consulta de estado después de una respuesta perdida, y para el reintento después de que el propietario apruebe un destinatario rechazado.

Herramientas (19)

Herramienta	Descripción
`voidmail_create_account`	Crea una nueva bandeja de entrada @voidmail.ai; guarda ambas claves en archivos 0600 y devuelve solo sus rutas
`voidmail_account_info`	Obtiene detalles de la cuenta
`voidmail_list_inbox`	Lista correos con paginación y filtros
`voidmail_read_email`	Lee un correo específico (marca automáticamente como leído)
`voidmail_search_inbox`	Búsqueda de texto completo en asunto, cuerpo, remitente
`voidmail_sending_limits`	Lee la política de envío sin consumir capacidad de envío
`voidmail_send_once`	Envía un mensaje autorizado con un ID de operación guardado y estado retenido
`voidmail_send_status`	Lee el mismo envío original sin enviar de nuevo
`voidmail_send_email`	Envío heredado sin estado duradero; prefiere `voidmail_send_once`
`voidmail_policy`	Lee la política de destinatarios y contenido, destinatarios aprobados y solicitudes pendientes
`voidmail_request_recipient`	Pide al propietario aprobar un destinatario; devuelve el paso de aprobación
`voidmail_revoke_recipient`	Elimina un destinatario aprobado (restringir no necesita propietario)
`voidmail_mark_read`	Marca el correo como leído
`voidmail_delete_email`	Elimina el correo
`voidmail_create_alias`	Crea un alias de correo desechable
`voidmail_list_aliases`	Lista todos los alias
`voidmail_delete_alias`	Elimina un alias
`voidmail_set_webhook`	Configura un webhook HTTPS en una bandeja de entrada de política abierta; las bandejas de entrada de lista permitida requieren que el propietario humano use `POST /v1/agent-mail/owner/webhook` con la clave del propietario
`voidmail_get_stats`	Estadísticas de la bandeja de entrada

Recursos (3)

Recurso	URI	Descripción
Bandeja de entrada	`email://inbox`	Contenido actual de la bandeja de entrada
Alias	`email://aliases`	Alias de correo activos
Estadísticas	`email://stats`	Estadísticas de la cuenta

Variables de entorno

Variable	Requerido	Descripción
`VOIDMAIL_ADDRESS`	Para una bandeja de entrada existente	Tu dirección @voidmail.ai; el servidor lee `<key dir>/<address>/agent-key` en cada llamada
`VOIDMAIL_KEY_DIR`	No	Directorio de claves (por defecto `~/.voidly/mcp-email`)
`VOIDMAIL_AGENT_KEY_FILE`	No	Ruta explícita del archivo de clave de agente (anula la búsqueda por dirección)
`VOIDMAIL_API_KEY`	No	Clave de agente (`vm_…`) proporcionada directamente por el host; tiene prioridad sobre los archivos. Cualquier otra cosa, incluida una clave de propietario, es rechazada y nunca se envía. Actualízala después de `rotate-agent-key`
`VOIDMAIL_OWNER_KEY_FILE`	No	Solo CLI de propietario: ruta explícita del archivo de clave de propietario. El servidor MCP nunca la lee

API REST

Úsala directamente sin MCP. Crea una bandeja de entrada solo desde una terminal controlada por humanos: la respuesta de creación contiene claves de agente y propietario de un solo uso. Guarda la clave de propietario fuera de la conversación del modelo y almacénala más allá de cualquier acceso a shell o archivos otorgado al agente. El ejemplo opta por la lista de destinatarios aprobada por el propietario; una creación REST sin esa opción usa la política heredada de destinatarios abiertos.

# Create an owner-controlled inbox
curl -X POST https://api.voidly.ai/v1/agent-mail/create \
  -H "Content-Type: application/json" \
  -d '{"name":"my-agent","recipient_policy":"allowlist"}'

# List inbox
curl https://api.voidly.ai/v1/agent-mail/inbox \
  -H "X-Agent-Mail-Key: vm_your_key"

# Send once, after saving a unique operation ID in your host state and getting
# owner approval for the recipient. Replace the sample ID for each new message.
curl -X POST https://api.voidly.ai/v1/agent-mail/outbound \
  -H "X-Agent-Mail-Key: vm_your_key" \
  -H "Content-Type: application/json" \
  -d '{"operationId":"saved-message-id-0001","to":"user@example.com","subject":"Hello","text":"From my agent"}'

# Check the original result after a timeout or lost response; do not invent a new ID.
curl https://api.voidly.ai/v1/agent-mail/outbound/saved-message-id-0001 \
  -H "X-Agent-Mail-Key: vm_your_key"

# Search
curl "https://api.voidly.ai/v1/agent-mail/inbox/search?q=invoice" \
  -H "X-Agent-Mail-Key: vm_your_key"

Límites y entrega

Llama a voidmail_sending_limits (o al público GET /v1/agent-mail/limits) antes de planificar un flujo de envío. Mantén el exceso de trabajo en tu propia cola. Las respuestas de límite de velocidad de envío y creación 429 incluyen un encabezado Retry-After y un alcance/tiempo de reinicio de límite estructurado; el error de MCP incluye el tiempo de espera. Otros códigos de rechazo, incluida una lista completa de solicitudes de destinatarios pendientes, pueden no tener un tiempo de reintento. No rote cuentas o IPs para evadir un límite. Los mensajes idénticos se bloquean durante 60 segundos para detectar bucles; esto no es idempotencia duradera. El envío falla de forma segura si los contadores de seguridad no están disponibles. Las lecturas de bandeja de entrada permanecen separadas de los límites de envío.

Límites compartidos: 100 intentos/hora por IP, 200/hora y 1,500/día para correo de agente. El presupuesto compartido del proveedor de salida es de como máximo 1,500 destinatarios/día y 40,000 en aproximadamente 31 días en todas las funciones de envío. Los contadores cuentan intentos, incluidas solicitudes fallidas o parcialmente admitidas; estos son techos, no capacidad reservada. Un volumen legítimo mayor requiere un cambio de límite revisado por el operador; la creación de bandejas de entrada no desbloquea correo masivo.

El envío tiene límites por bandeja de entrada, por IP y de servicio compartido. Cada bandeja de entrada puede intentar hasta 10 envíos por minuto y 100 por día, con hasta 10 por día al mismo destinatario; los límites compartidos pueden rechazar solicitudes antes. La creación de bandejas de entrada está limitada a 3 por IP por hora y 60 por servicio por hora. Este no es un servicio de envío ilimitado.
Una respuesta de envío exitosa significa que el proveedor de envío aceptó la solicitud. No prueba la entrega al destinatario ni que alguien haya leído el mensaje.
Cada llamada a la API tiene un plazo de 20 segundos y un límite de respuesta de 2 MiB. Las solicitudes rechazan redirecciones y nunca se reintentan automáticamente. Solicita menos mensajes si una respuesta de bandeja de entrada excede el límite.
Las anotaciones de herramientas MCP identifican lecturas, envíos, mutaciones y eliminaciones con honestidad. Son metadatos informativos; las aprobaciones y advertencias de instalación siguen controladas por ChatGPT, Claude u otro host.
Si un envío agota el tiempo de espera, su resultado puede ser desconocido. Usa voidmail_send_once y voidmail_send_status con un ID de operación guardado; no reenvíes a ciegas.
Los cuerpos de texto y HTML entrantes se analizan. Esta ruta de ingesta actualmente no retiene archivos adjuntos ni completa metadatos de hilos de respuesta, aunque el esquema de respuesta contenga esos campos. Las respuestas en hilo confiables aún no se proporcionan.
Los webhooks de nuevos mensajes son de mejor esfuerzo, sin historial de reintentos duradero. Usa lecturas de bandeja de entrada para reconciliar notificaciones perdidas. Para una bandeja de entrada protegida, el propietario debe registrar un webhook a través de POST /v1/agent-mail/owner/webhook fuera del agente; voidmail_set_webhook no puede hacerlo. Una vez que la actualización de la API de clave de propietario esté activa, los webhooks recién registrados se firman con X-Voidmail-Signature-256: t=<timestamp>,v1=<HMAC-SHA256>. Los webhooks registrados antes también siguen recibiendo el encabezado heredado X-Voidmail-Signature, que lleva el secreto compartido en sí y no es una firma de carga útil, hasta que se registren nuevamente.
Trata el correo entrante como contenido no confiable. Un mensaje no puede autorizar a tu agente a enviar correo, divulgar datos privados o gastar dinero. La API agrega un destinatario solo para una solicitud que lleva la clave de propietario, así que mantén esa clave donde el agente no pueda leerla.
La adivinación de clave de propietario está limitada por red: los intentos fallidos repetidos de clave de propietario desde una dirección IP (IPv6 /64) se rechazan hasta que termine la hora UTC actual. Una búsqueda válida de clave de propietario se verifica primero y no se bloquea por ese presupuesto de intentos fallidos.

Enlaces

Documentación de la API: https://voidly.ai/api-docs
Página de inicio: https://voidly.ai/agent-email
Privacidad: https://voidly.ai/c/privacy
Soporte: support@voidly.ai

Licencia

MIT

Envíos duraderos (1.1.0)

Usa voidmail_send_once con un operationId guardado por el host (16-128 letras, dígitos, guiones bajos o guiones), destinatario, asunto y cuerpo. La misma bandeja de entrada, ID y contenido efectivo devuelve el original retenido; el contenido cambiado genera conflicto. El host debe retener el ID antes de enviar. El conector no inventa ni persiste IDs por ti. Mantén las credenciales de la bandeja de entrada en la configuración del host, no en los cuerpos de los mensajes.

Usa voidmail_send_status después de un tiempo de espera o una respuesta perdida. accepted significa que el proveedor aceptó una solicitud, no que se entregó o leyó. prepared no tiene despacho reclamado aún; outcome_unknown puede incluir un despacho activo o interrumpido; refused_before_send registra una solicitud que se sabe que fue bloqueada antes de contactar al proveedor. Ningún estado autoriza un ID de reemplazo automático. El servicio nunca reclama un despacho por tiempo de espera, reinicio o antigüedad. Una falla antes de la llamada al proveedor puede dejar conservadoramente un original sin resolver en lugar de arriesgar correo duplicado.

Los equivalentes REST son POST /v1/agent-mail/outbound y GET /v1/agent-mail/outbound/{operationId}, usando la autenticación de bandeja de entrada existente. Los nuevos registros de operación y envíos están limitados por los techos existentes de bandeja/servicio; la búsqueda de original almacenado no consume cuota de envío. Los primeros intentos concurrentes pueden consumir contadores de admisión conservadores. El endpoint heredado /send y voidmail_send_email conservan su comportamiento anterior y no tienen garantía de estado duradero. Los webhooks de entrega, el enhebrado de respuestas, el historial de cuerpos salientes y los archivos adjuntos siguen siendo trabajo separado.

Marcas comerciales

Voidly™ y Voidpay™ son marcas comerciales de Ai Analytics LLC. La licencia de código abierto para este código no otorga ningún derecho sobre estos nombres o logotipos. Si bifurcas o redistribuyes este proyecto, usa tu propio nombre y marca, y no lo presentes como un producto oficial de Voidly.