Un asistente que lee el correo, crea buzones y corrige el DNS puede ahorrar mucho trabajo. Pero también puede borrar el buzón equivocado si interpreta mal cuál querías eliminar.
Por eso, la cuestión principal de un servidor MCP para correo no es qué puede hacer el agente, sino qué ocurre cuando se equivoca. Los permisos y las restricciones que rodean al servidor determinan buena parte de las consecuencias. No basta con confiar en la capacidad del modelo.
Veremos qué es un servidor MCP, qué tareas permite realizar en una plataforma de correo y qué medidas reducen el riesgo: separar los tokens, limitar los permisos, confirmar las operaciones destructivas y mantener un registro de actividad. Ninguna de ellas garantiza por sí sola que el trabajo autónomo sea seguro.
Qué es un servidor MCP
El Model Context Protocol ofrece una forma común de que un cliente de IA descubra y utilice herramientas de un sistema externo. El servidor MCP publica las herramientas con su nombre, descripción y esquema de argumentos. El cliente presenta esa información al modelo. Cuando este elige una herramienta, el cliente ejecuta la llamada y devuelve el resultado.
La ventaja es que la integración no queda ligada a un único cliente. Un mismo servidor puede funcionar con Claude Desktop, Claude Code, Cursor, Windsurf y otras aplicaciones compatibles. Aun así, hay que comprobar el transporte, la autorización y las funciones que admite cada cliente. El protocolo reduce el trabajo específico por aplicación, pero no elimina la configuración de la conexión.
En una plataforma de correo, esta estructura encaja bien: muchas operaciones ya están disponibles mediante una API. El servidor MCP las describe como herramientas sobre la API REST. Por tanto, las restricciones no dependen solo del agente: deben aplicarlas la API, el servidor y la integración del cliente.
Qué puede hacer un agente a través del servidor MCP
La versión descrita en el texto original ofrece más de 200 herramientas, agrupadas aproximadamente así. El conjunto disponible depende de la versión, la configuración, los permisos y el plan:
| Área | Ejemplos |
|---|---|
| Dominios y DNS | Añadir dominios, consultar los registros necesarios, iniciar comprobaciones de DNS, aplicar cambios mediante Cloudflare y reintentar la configuración de DKIM |
| Buzones | Crear, listar, actualizar, pausar, cambiar contraseñas, gestionar alias y reenvíos y restaurar desde la papelera |
| Mensajes | Leer, buscar, enviar, responder, reenviar, preparar borradores, programar envíos, mover, marcar y denunciar spam o indicar que un mensaje no es spam |
| Carpetas y reglas | Crear y renombrar carpetas, gestionar filtros, cargar código Sieve y configurar respuestas automáticas |
| Contactos y calendario | Crear y actualizar contactos y grupos, importar y exportar y crear y actualizar eventos |
| Drive | Explorar, subir, mover, compartir, realizar operaciones por lotes y gestionar contraseñas para dispositivos de sincronización |
| Migración | Probar conexiones, iniciar importaciones, consultar el progreso por carpeta, cancelar y reintentar |
| Entregabilidad | Consultar resúmenes de envío y entrega y rebotes por destinatario con la respuesta SMTP del servidor receptor |
| Marca | Configurar la marca propia por dominio, obtener los CNAME necesarios y verificar el DNS |
| Soporte y facturación | Consultar incidencias, facturas y el estado del plan |
Algunas herramientas permiten evitar que el modelo reciba secretos. La configuración del cliente de correo se obtiene como datos estructurados: servidores, puertos y nombres de usuario para Outlook, sin la contraseña del buzón. También se generan perfiles para Apple Mail. El agente puede ayudar a un empleado a configurar su correo sin conocer la contraseña. Otras herramientas sí pueden manejar credenciales, así que revisa sus permisos y sus respuestas por separado.
Por qué hay distintos tipos de token
Una decisión importante para los tokens estáticos es separar el acceso a la infraestructura del acceso al contenido de los mensajes. Las conexiones OAuth también deben respetar los permisos concedidos durante la autorización.
Token de administración (tm_live_) | Token de mensajes (tm_msg_) | |
|---|---|---|
| Acceso | Dominios, buzones, DNS, reenvío, facturación y migraciones, dentro de los permisos concedidos | Contenido de mensajes, carpetas, adjuntos, contactos y calendario, dentro de los permisos concedidos |
| No permite directamente | Leer el cuerpo de un mensaje mediante la API de mensajes | Crear un buzón o modificar el DNS |
| Uso habitual | Un script de aprovisionamiento o un asistente de administración | Un asistente que organiza la bandeja de entrada |
La separación reduce el alcance de una equivocación. Una automatización que crea buzones para nuevas incorporaciones no necesita leer su correo. Un asistente que prepara respuestas no necesita borrar dominios. Sin embargo, unos permisos administrativos amplios para gestionar tokens de mensajes, contraseñas o reenvíos pueden abrir una vía indirecta de acceso. Limita las facultades reales, no solo el tipo de token.
Por tanto, la filtración de un token administrativo sigue siendo un incidente grave. El token no lee directamente el cuerpo de un mensaje, pero las consecuencias dependen de lo que tenga permiso para cambiar o crear.
Permisos generales y permisos detallados
Dentro de cada tipo de token, los permisos restringen aún más el acceso. En OAuth se combinan grupos comprensibles para el usuario con comprobaciones más precisas en la API.
El esquema original mostraba cinco grupos generales de permisos en la pantalla de consentimiento: mail:read, mail:write, mail:admin, messages:read y messages:send. Una lista breve resulta más fácil de evaluar que decenas de detalles. Ahora existen permisos adicionales, así que lee la pantalla que aparece realmente: por ejemplo, gestionar borradores y enviar mensajes son capacidades distintas.
La API comprueba los permisos detallados para cada operación. Leer la configuración de reenvío y modificarla, por ejemplo, requiere facultades diferentes. Los grupos sencillos al conceder acceso no deben sustituir las comprobaciones precisas cuando se ejecuta una solicitud.
Los permisos también dependen del plan y de las prestaciones vigentes de la cuenta. La descripción original limita Nano a la verificación de direcciones, ofrece lectura y verificación en Starter y amplía las operaciones en Pro y Agency. Las prestaciones actuales pueden incluir capacidades adicionales, como las de Drive o servicios contratados por separado. Comprueba los permisos disponibles al emitir el token en lugar de guiarte solo por el nombre del plan.
Regla práctica: emite un token por automatización con los permisos mínimos que necesita. No lo reutilices para tareas diferentes. Un token compartido por varios scripts reúne sus facultades y dificulta saber cuál ejecutó cada acción. Consulta permisos y ámbitos de la API.
Confirmación de operaciones destructivas
Que el modelo responda con seguridad no significa que haya elegido el recurso correcto. Confiar en esa seguridad es especialmente peligroso al borrar.
Para eliminar un buzón, la primera llamada crea una solicitud previa de eliminación que no borra nada. Describe lo que ocurriría al confirmarla y devuelve información sobre el recurso y los riesgos, incluidas sus relaciones y las migraciones activas. Por defecto, caduca a los diez minutos. No supongas que los dominios siguen el mismo procedimiento: su eliminación funciona de otra manera.
La siguiente llamada confirma la solicitud y exige una cabecera de confirmación explícita. Revisar las consecuencias entre ambas llamadas ayuda, pero no garantiza protección: un agente con acceso a las dos herramientas puede ejecutar ambos pasos. Si necesitas supervisión humana, establece una aprobación independiente y restringe el acceso a la confirmación.
El buzón eliminado pasa primero a la papelera. Se puede restaurar durante el periodo de retención, pero no después de su purga definitiva. Los dominios no tienen una papelera equivalente. La API rechaza la eliminación de dominios con buzones activos y exige resolver las relaciones con dominios alias. La eliminación de una cuenta tiene sus propias consecuencias y no se vuelve reversible por el procedimiento de los buzones.
El envío y las migraciones cuentan con restricciones específicas. Consulta medidas de protección y solicitudes de eliminación.
Idempotencia al reintentar solicitudes
Tras un tiempo de espera agotado, el agente puede reintentar la solicitud, igual que cualquier cliente. Si la operación ya se completó y solo se perdió la respuesta, un reintento ingenuo puede crear el recurso otra vez.
En las operaciones correspondientes que modifican datos, la API utiliza una clave de idempotencia. Repite la misma solicitud con la misma clave mientras el resultado siga conservado. Así, la API puede devolver la respuesta guardada en lugar de ejecutar otra vez la operación. Cambiar los datos con la misma clave provoca un conflicto; no se trata de una garantía indefinida contra duplicados. Importa tanto al crear buzones como al enviar mensajes: un envío duplicado no da buena imagen ante el cliente.
Los límites pueden aplicarse por token, cuenta o buzón. Cuando se rechaza una solicitud por exceso de uso, el cliente debe respetar Retry-After y esperar. Las operaciones destructivas tienen límites más estrictos. Estos contienen un bucle erróneo, pero no deshacen el daño de las acciones ya ejecutadas.
Para qué sirve el registro de auditoría
El panel muestra eventos de auditoría con el token, la operación, el recurso y la fecha. El periodo de retención predeterminado es de 90 días. No asumas que registra todas las llamadas: la cobertura depende de la operación y la configuración, y las lecturas de mensajes pueden registrarse por muestreo.
El registro no sirve solo para presentar informes. Permite reconstruir lo sucedido cuando no puedes observar al agente continuamente. Por ejemplo, averiguar quién configuró un reenvío a una dirección desconocida. Aun así, no sustituye los límites de acceso ni necesariamente contiene datos suficientes para responder a cualquier pregunta.
También ayuda a detectar actividad inesperada de un token. Revocar un token concreto limita las llamadas futuras de esa automatización. Pero hay que revisar por separado las acciones ya realizadas y otras credenciales que sigan vigentes.
Automatizaciones que merece la pena crear
Las tareas más útiles suelen ser las menos vistosas.
Altas y bajas de empleados.Una incorporación necesita buzón, alias, grupos e instrucciones de configuración. Una baja exige retirar el acceso y decidir qué hacer con los reenvíos y el archivo. La automatización ayuda a seguir una lista de comprobación, pero hay que revisar el resultado. No garantiza una ejecución correcta en todos los casos.
Aprovisionamiento de dominios para una agencia.Añadir el dominio, configurar el DNS, crear los buzones, verificar y presentar un informe. Las tareas repetitivas de puesta en marcha encajan bien en una automatización con permisos acordados.
Seguimiento de la entregabilidad.Obtener datos de rebotes con la respuesta SMTP del receptor, agrupar las causas y destacar posibles errores de configuración. Un resumen semanal ayuda a detectar problemas con un registro SPF, pero no garantiza descubrir todos los fallos de entrega.
Supervisión de migraciones.Iniciar un lote, seguir el progreso por carpeta, revisar errores y preparar un informe de comprobación. No confundas una tarea terminada con una copia completa; consulta migración por lotes.
Revisión de la bandeja de entrada con acceso de solo lectura.El agente puede resumir mensajes y proponer categorías. Con ese token no puede enviar, pero tampoco cambiar marcas sin un permiso de escritura. Para aplicar categorías y marcas, concede solo las facultades necesarias, sin permiso de envío.
Qué conviene evitar
No concedas todos los permisos a un token para simplificar la configuración. Puede seguir activo años después con facultades excesivas.
No permitas que el agente envíe sin supervisión a destinatarios externos hasta haber revisado la calidad de sus borradores. Preparar borradores y enviar requiere permisos diferentes, aunque algunos grupos generales pueden incluir ambas capacidades. Comprueba los permisos concedidos realmente.
No guardes tokens en el repositorio.Utiliza variables de entorno o un gestor de secretos que no se incluya en Git. Comprueba también que los secretos no aparezcan en registros ni respuestas de herramientas.
No ignores el registro de auditoría.Revísalo durante la primera semana. Compara los eventos con las acciones esperadas y averigua qué operaciones no quedan registradas.
No automatices la eliminación de dominios.No tienen papelera. Estas operaciones necesitan una persona que compruebe el recurso y las consecuencias, no que se limite a repetir la confirmación del modelo.
Preguntas frecuentes
¿Qué clientes de IA funcionan con el servidor MCP?
Aplicaciones compatibles con MCP, como Claude Desktop, Claude Code, Cursor y Windsurf. El protocolo simplifica la integración, pero hay que comprobar el transporte, la autorización, la versión del cliente y la configuración de la conexión.
¿Puede el agente leer mi correo?
Para leer directamente mediante la API de mensajes necesita un token de mensajes con permiso de lectura o una autorización OAuth adecuada. Un token administrativo no lee directamente el cuerpo, pero los permisos amplios para crear tokens, cambiar contraseñas o configurar reenvíos pueden abrir un acceso indirecto. No los concedas sin necesidad.
¿Qué impide que el agente borre algo importante?
Para los buzones existe una solicitud previa que caduca por defecto a los diez minutos y una confirmación posterior con una cabecera explícita. El buzón puede restaurarse desde la papelera antes de su purga definitiva. Esto no garantiza una revisión humana. La eliminación de dominios sigue otro procedimiento, no tiene papelera y no debería ejecutarse de forma autónoma.
¿El servidor MCP envía mi correo al proveedor de IA?
Los datos que obtiene el agente pueden llegar al modelo utilizado, según el cliente y dónde se ejecute. Con un modelo en la nube, eso puede implicar una transferencia a un proveedor externo; el procesamiento local funciona de otra manera. Limita el acceso y revisa las condiciones de tratamiento de datos y las vías indirectas para obtener correo. Impedir la lectura directa no garantiza por sí solo que no haya filtraciones.
¿Necesito otro token para las operaciones con mensajes?
En los tokens estáticos, la infraestructura y los mensajes usan tipos distintos. En OAuth se tienen en cuenta los permisos de autorización y los tokens creados para esa conexión. La separación reduce el riesgo, pero no convierte en seguros todos los permisos administrativos amplios.
¿Qué pasa si el agente alcanza un límite de uso?
La solicitud se rechaza y el cliente debe respetar Retry-After antes de reintentar, si corresponde. Los límites destructivos son más estrictos, pero no garantizan que un bucle erróneo no cause daños antes de detenerse.
¿Puedo ver qué hizo el agente la semana pasada?
El registro del panel muestra los eventos guardados, el token y el recurso afectado. Por defecto se conservan 90 días. Ten en cuenta la cobertura y el muestreo de algunas lecturas: el registro no necesariamente contiene todas las llamadas.
¿El acceso al servidor MCP tiene un coste adicional?
La descripción original incluye API y MCP en el plan: Nano se orienta a verificar direcciones, Starter ofrece operaciones limitadas y Pro y Agency amplían las capacidades. Comprueba las prestaciones vigentes de la cuenta y sus permisos. Los servicios adicionales, los créditos consumibles y el uso de un modelo externo pueden cobrarse por separado.
