Um assistente que lê e-mails, cria caixas de correio e corrige o DNS pode poupar bastante trabalho. Mas também pode excluir a caixa errada se interpretar mal qual você queria remover.
Por isso, a principal questão sobre um servidor MCP para e-mail não é o que o agente consegue fazer, mas o que acontece quando ele erra. As permissões e as restrições ao redor do servidor determinam boa parte das consequências. Confiar apenas na capacidade do modelo não basta.
Veja o que é um servidor MCP, quais tarefas ele permite executar em uma plataforma de e-mail e quais medidas reduzem o risco: separar os tokens, limitar as permissões, confirmar operações destrutivas e manter um registro de atividades. Nenhuma delas, sozinha, garante uma operação autônoma segura.
O que é um servidor MCP
O Model Context Protocol define uma forma comum para um cliente de IA descobrir e chamar ferramentas de um sistema externo. O servidor MCP publica as ferramentas com nome, descrição e esquema dos argumentos. O cliente apresenta essas informações ao modelo. Quando o modelo escolhe uma ferramenta, o cliente executa a chamada e devolve o resultado.
A vantagem é não depender de um único cliente. O mesmo servidor pode funcionar com Claude Desktop, Claude Code, Cursor, Windsurf e outras aplicações compatíveis. Ainda assim, é preciso conferir o transporte, a autorização e os recursos suportados. O protocolo reduz o trabalho específico de integração por aplicação, mas não elimina a configuração da conexão.
Essa estrutura faz sentido para uma plataforma de e-mail: muitas operações já estão disponíveis por API. O servidor MCP as descreve como ferramentas sobre a API REST. Portanto, as restrições não dependem apenas do agente. A API, o servidor e a integração do cliente precisam aplicá-las.
O que um agente pode fazer pelo servidor MCP
A versão descrita no texto original oferece mais de 200 ferramentas, distribuídas aproximadamente nos grupos abaixo. O conjunto disponível depende da versão, da configuração, das permissões e do plano:
| Área | Exemplos |
|---|---|
| Domínios e DNS | Adicionar domínios, consultar os registros necessários, iniciar verificações de DNS, aplicar configurações pelo Cloudflare e tentar configurar o DKIM novamente |
| Caixas de e-mail | Criar, listar, atualizar, pausar, alterar senhas, gerenciar aliases e encaminhamentos e restaurar da lixeira |
| Mensagens | Ler, pesquisar, enviar, responder, encaminhar, preparar rascunhos, agendar envios, mover, marcar e denunciar spam ou indicar que uma mensagem não é spam |
| Pastas e regras | Criar e renomear pastas, gerenciar filtros, enviar código Sieve e configurar respostas automáticas |
| Contatos e calendário | Criar e atualizar contatos e grupos, importar e exportar e criar e atualizar eventos |
| Drive | Navegar, enviar arquivos, mover, compartilhar, executar operações em lote e gerenciar senhas de dispositivos de sincronização |
| Migração | Testar conexões, iniciar importações, acompanhar o progresso por pasta, cancelar e tentar novamente |
| Entregabilidade | Consultar resumos de envio e entrega e devoluções por destinatário com a resposta SMTP do servidor receptor |
| Identidade visual | Configurar a marca própria por domínio, obter os CNAMEs necessários e verificar o DNS |
| Suporte e cobrança | Consultar chamados, faturas e o estado do plano |
Algumas ferramentas evitam que o modelo receba segredos. As configurações do cliente de e-mail podem ser obtidas como dados estruturados: servidores, portas e nomes de usuário para o Outlook, sem a senha da caixa. Também é possível gerar perfis de configuração para o Apple Mail. O agente pode ajudar um funcionário a configurar o e-mail sem conhecer sua senha. Outras ferramentas podem lidar com credenciais, por isso confira suas permissões e respostas separadamente.
Por que separar os tokens
Uma decisão importante para tokens estáticos é separar o acesso à infraestrutura do acesso ao conteúdo das mensagens. Nas conexões OAuth, também valem as permissões concedidas durante a autorização.
Token administrativo (tm_live_) | Token de mensagens (tm_msg_) | |
|---|---|---|
| Acesso | Domínios, caixas, DNS, encaminhamento, cobrança e migrações, dentro das permissões concedidas | Conteúdo de mensagens, pastas, anexos, contatos e calendário, dentro das permissões concedidas |
| Não permite diretamente | Ler o corpo de uma mensagem pela API de mensagens | Criar uma caixa ou alterar o DNS |
| Uso habitual | Script de provisionamento ou assistente de administração | Assistente que organiza a caixa de entrada |
A separação reduz o alcance de um erro. Uma automação que cria caixas para novos funcionários não precisa ler seus e-mails. Um assistente que prepara respostas não precisa excluir um domínio. Porém, permissões administrativas amplas para gerenciar tokens de mensagens, senhas ou encaminhamentos podem abrir um caminho indireto para o e-mail. Limite as capacidades reais, não apenas o tipo de token.
Portanto, o vazamento de um token administrativo continua sendo um incidente grave. Ele não lê diretamente o corpo das mensagens, mas as consequências dependem do que pode alterar ou criar.
Permissões gerais e detalhadas
Dentro de cada tipo de token, as permissões restringem ainda mais o acesso. O OAuth combina grupos compreensíveis para o usuário com verificações mais precisas na API.
O esquema original mostrava cinco grupos gerais de permissões na tela de consentimento: mail:read, mail:write, mail:admin, messages:read e messages:send. Uma lista curta é mais fácil de avaliar do que dezenas de detalhes. Hoje existem permissões adicionais. Leia a tela que aparece de fato: gerenciar rascunhos e enviar mensagens, por exemplo, são capacidades diferentes.
A API verifica as permissões detalhadas para cada operação. Ler a configuração de encaminhamento e alterá-la exige, por exemplo, autorizações diferentes. Grupos simples na concessão de acesso não devem substituir as verificações precisas durante a execução.
As permissões também dependem do plano e dos recursos atuais da conta. A descrição original limita o Nano à verificação de endereços, oferece leitura e verificação no Starter e amplia as operações no Pro e no Agency. As permissões atuais podem incluir recursos adicionais, como os do Drive ou serviços contratados separadamente. Confira os direitos disponíveis ao emitir o token, em vez de se guiar apenas pelo nome do plano.
Regra prática: emita um token por automação com as permissões mínimas necessárias. Não o reutilize para tarefas diferentes. Um token compartilhado por vários scripts reúne suas capacidades e dificulta identificar qual script executou cada ação. Consulte escopos e permissões da API.
Confirmação de operações destrutivas
Uma resposta confiante do modelo não significa que ele escolheu o recurso certo. Confiar nisso é especialmente perigoso na hora de excluir.
Para excluir uma caixa, a primeira chamada cria uma intenção de exclusão que não exclui nada. Ela descreve o que aconteceria após a confirmação e retorna informações sobre o recurso e os riscos, incluindo configurações relacionadas e migrações ativas. Por padrão, expira em dez minutos. Não presuma que esse procedimento vale para domínios: a exclusão deles segue outro fluxo.
A chamada seguinte confirma a intenção e exige um cabeçalho explícito de confirmação. Conferir as consequências entre as chamadas ajuda, mas não garante proteção: um agente com acesso às duas ferramentas pode executar as duas etapas. Se for necessária aprovação humana, organize uma autorização independente e restrinja o acesso à confirmação.
A caixa excluída vai primeiro para a lixeira. Pode ser restaurada durante o prazo de retenção, mas não após a remoção definitiva. Os domínios não têm uma lixeira equivalente. A API rejeita a exclusão de domínios com caixas ativas e exige resolver as conexões com domínios de alias. A exclusão da conta tem suas próprias consequências e não se torna reversível pelo procedimento das caixas.
Envios e migrações têm restrições específicas. Consulte proteções e intenções de exclusão.
Idempotência nas novas tentativas
Depois de um tempo limite excedido, o agente pode repetir a solicitação, como qualquer cliente. Se a operação já foi concluída e apenas a resposta se perdeu, uma repetição sem os devidos cuidados pode criar o recurso novamente.
Nas operações correspondentes que alteram dados, a API usa uma chave de idempotência. Repita a mesma solicitação com a mesma chave enquanto o resultado estiver armazenado. Assim, a API pode devolver a resposta salva em vez de executar a operação de novo. Alterar os dados com a mesma chave gera um conflito; o mecanismo não é uma garantia eterna contra duplicações. Isso importa tanto para criar caixas quanto para enviar mensagens. Um envio duplicado passa uma impressão ruim para o cliente.
Os limites podem valer por token, conta ou caixa. Quando uma solicitação é rejeitada por excesso de uso, o cliente deve respeitar Retry-After e esperar. Operações destrutivas têm limites mais rígidos. Eles contêm um ciclo incorreto, mas não desfazem os danos das ações já executadas.
Para que serve o registro de auditoria
O painel mostra eventos de auditoria com o token, a operação, o recurso e a data. O prazo padrão de retenção é de 90 dias. Isso não garante que todas as chamadas sejam registradas: a cobertura depende da operação e das configurações, e as leituras de mensagens podem ser registradas por amostragem.
O registro não serve apenas para gerar relatórios. Ele ajuda a reconstruir as ações quando você não pode observar o agente o tempo todo. Por exemplo, descobrir quem configurou um encaminhamento para um endereço desconhecido. Mas não substitui as restrições de acesso nem necessariamente contém informações suficientes para responder a qualquer pergunta.
Ele também ajuda a detectar atividades inesperadas de um token. Revogar um token específico limita as chamadas futuras daquela automação. As ações já realizadas e outras credenciais ainda válidas precisam ser examinadas separadamente.
Automações que valem a pena
As tarefas mais úteis costumam ser as menos chamativas.
Entrada e saída de funcionários.Um novo funcionário precisa de caixa, aliases, grupos e instruções de configuração. Quando ele sai, é preciso retirar acessos e decidir como tratar os encaminhamentos e o arquivamento. A automação ajuda a seguir uma lista de verificação, mas o resultado ainda precisa ser conferido. Não há garantia de execução correta em todos os casos.
Provisionamento de domínios para clientes de uma agência.Adicionar o domínio, configurar o DNS, criar as caixas, verificar e emitir um relatório. Etapas repetitivas de configuração se prestam à automação dentro das permissões acordadas.
Monitoramento da entregabilidade.Obter devoluções com a resposta SMTP do servidor receptor, agrupar causas e destacar possíveis erros de configuração. Um resumo semanal pode revelar problemas em um registro SPF, mas não garante detectar todas as falhas de entrega.
Supervisão de migrações.Iniciar um lote, acompanhar o progresso por pasta, revisar erros e preparar um relatório de conferência. Uma tarefa concluída não prova que a cópia está completa; veja migração de e-mail em lote.
Triagem da caixa de entrada com acesso somente de leitura.O agente pode resumir mensagens e sugerir categorias. Esse token não permite enviar, mas também não permite alterar marcações sem permissão de escrita. Para aplicar categorias e marcações, conceda apenas os direitos necessários, sem autorização de envio.
O que evitar
Não conceda todas as permissões a um token só para facilitar a configuração. Ele pode continuar ativo anos depois com poderes excessivos.
Não deixe o agente enviar sozinho para destinatários externos antes de avaliar a qualidade dos rascunhos. Preparar rascunhos e enviar exige permissões distintas, embora alguns grupos gerais possam incluir ambas. Confira os direitos realmente concedidos.
Não guarde tokens no repositório.Use variáveis de ambiente ou um gerenciador de segredos que não seja incluído no Git. Confira também se os segredos aparecem em registros ou respostas das ferramentas.
Não ignore o registro de auditoria.Consulte-o na primeira semana. Compare os eventos com as ações esperadas e descubra quais operações não ficam registradas.
Não automatize a exclusão de domínios.Eles não têm lixeira. Essas operações precisam de uma pessoa que confira o recurso e as consequências, não apenas repita a confirmação do modelo.
Perguntas frequentes
Quais clientes de IA funcionam com o servidor MCP?
Aplicações compatíveis com MCP, como Claude Desktop, Claude Code, Cursor e Windsurf. O protocolo facilita a integração, mas é preciso conferir o transporte, a autorização, a versão do cliente e a configuração da conexão.
O agente pode ler meus e-mails?
Para ler diretamente pela API de mensagens, precisa de um token de mensagens com permissão de leitura ou de uma autorização OAuth adequada. Um token administrativo não lê diretamente o corpo. Porém, permissões amplas para criar tokens, alterar senhas ou configurar encaminhamentos podem abrir um acesso indireto. Não as conceda sem necessidade.
O que impede o agente de excluir um recurso importante?
Para caixas, existe uma intenção de exclusão que expira por padrão em dez minutos e uma confirmação posterior com cabeçalho explícito. A caixa pode ser restaurada da lixeira antes da remoção definitiva. Isso não garante aprovação humana. A exclusão de domínios segue outro fluxo, não tem lixeira e não deve ser autônoma.
O servidor MCP envia meus e-mails ao fornecedor de IA?
Os dados obtidos pelo agente podem chegar ao modelo usado, conforme o cliente e o local de execução. Com um modelo na nuvem, isso pode significar transferência para um fornecedor externo; o processamento local é diferente. Limite o acesso, confira as condições de tratamento dos dados e os caminhos indiretos para obter e-mails. Impedir a leitura direta não garante, por si só, a ausência de vazamentos.
Preciso de outro token para operações com mensagens?
Tokens estáticos usam tipos diferentes para infraestrutura e mensagens. No OAuth, também contam as permissões concedidas e os tokens criados para a conexão. A separação reduz o risco, mas não torna seguras todas as permissões administrativas amplas.
O que acontece se o agente atingir um limite?
A solicitação é rejeitada. O cliente deve respeitar Retry-After e tentar mais tarde, se for apropriado. Os limites de operações destrutivas são mais rígidos, mas não garantem que um ciclo incorreto pare antes de causar danos.
Posso ver o que o agente fez na semana passada?
O registro do painel mostra os eventos armazenados, o token e o recurso afetado. Por padrão, eles são mantidos por 90 dias. Considere a cobertura e a amostragem de algumas leituras: nem todas as chamadas necessariamente aparecem no registro.
O acesso ao servidor MCP custa mais?
A descrição original inclui API e MCP no plano: Nano se destina à verificação de endereços, Starter oferece operações limitadas e Pro e Agency ampliam os recursos. Confira as funcionalidades atuais da conta e suas permissões. Serviços adicionais, créditos consumidos e o uso de um modelo externo podem ser cobrados separadamente.
