MCP do Google Workspace e Gmail MCP: o que realmente toca a sua caixa de entrada

Gmail, Calendar e Drive são o dado de maior sinal que um agente pode ler, e também o de maior risco. Sinal, porque uma caixa de entrada é o único lugar que já sabe com quem você trabalha, o que essas pessoas querem de você e quando isso vence. Risco, porque toda ferramenta que lê esses dados geralmente também consegue escrever neles, e uma caixa de entrada também é onde cai o reset de senha.

O MCP do Google Workspace não é uma coisa só. É um conjunto de servidores MCP, oficiais e open source, com modelos de auth diferentes, listas de ferramentas diferentes e raios de explosão diferentes. Antes de apontar um deles pra uma caixa de entrada, saiba exatamente quais ferramentas ele expõe e quem fica com o token.

O que o MCP do Google Workspace realmente cobre

Duas coisas diferentes respondem por “MCP do Google Workspace”, e misturar as duas é o primeiro erro. Servidores só de Gmail são uma terceira categoria, coberta mais abaixo.

O Google distribui os próprios servidores MCP remotos, um por produto: Gmail, Drive, Docs, Sheets, Slides, Calendar, Chat e a API do People, cada um no seu endpoint hospedado (gmailmcp.googleapis.com, drivemcp.googleapis.com, e assim por diante). Você não roda esses servidores. O Google roda, e o seu cliente MCP se autentica neles via OAuth 2.0, por um OAuth client que você cria no seu próprio projeto do Google Cloud. Eles exigem habilitar tanto a API do produto (gmail.googleapis.com) quanto uma segunda API, específica de MCP (gmailmcp.googleapis.com), seguindo o próprio guia de setup do Google.

Depois tem o meio-termo open source: taylorwilsdon/google_workspace_mcp, licenciado em MIT, com 3.268 estrelas no GitHub na data desta checagem. Um servidor, doze serviços (Gmail, Drive, Calendar, Docs, Sheets, Slides, Forms, Tasks, Contacts, Chat, Custom Search e Apps Script), mais de 120 ferramentas por trás disso. Você hospeda ele mesmo, aponta pro seu próprio OAuth client, e ele suporta tanto um modo single-user de “confidential client” quanto OAuth 2.1 completo com PKCE pra múltiplos usuários atrás de um único deploy.

Dois jeitos de colocar o Workspace num agente

Os dois colocam a tela de consentimento OAuth do Google entre o agente e a sua conta. Só um deles você consegue inspecionar.

	Servidores oficiais do Google	taylorwilsdon/google_workspace_mcp
Quem roda	Google (endpoint remoto)	Você (self-hosted)
Disponibilidade	Só no Developer Preview Program	Aberto pra qualquer um, licença MIT
Cobertura	Gmail, Drive, Docs, Sheets, Slides, Calendar, Chat, People	Esses 8 mais Forms, Tasks, Contacts, Search e Apps Script
Auth	OAuth 2.0, com client ID e secret seus	Seu próprio OAuth client; OAuth 2.1 PKCE pra multi-user
Controle de scope	O que você adicionar na tela de consentimento	Scopes OAuth, mais tiers de ferramenta e uma flag --read-only

Gmail MCP server: a lista de ferramentas é a fronteira de segurança de verdade

Leia a referência do próprio Google pro Gmail MCP server e a primeira coisa que chama atenção é o que está faltando. A lista de ferramentas é create_draft, get_thread, label_message, label_thread, list_drafts, list_labels, search_threads, unlabel_message e unlabel_thread. Não tem send_message. Não tem delete. Um agente conectado ao Gmail MCP server oficial do Google consegue ler o seu email, rotular e escrever um rascunho. Ele não consegue enviar nada sem você abrir o Gmail e clicar em enviar você mesmo.

Os scopes confirmam isso: o guia de setup do Google pede exatamente gmail.readonly e gmail.compose, não gmail.send e nem o scope genérico mail.google.com. Isso não é acidente. É o fato mais útil de todo esse assunto: quem construiu o Gmail MCP server oficial decidiu que um agente deveria rascunhar, não enviar.

Servidores de Gmail open source não fazem todos essa mesma escolha. O mais estrelado no GitHub, GongRzhe/Gmail-MCP-Server, com 1.164 estrelas, está arquivado e não recebe um commit desde agosto de 2025. Se você for procurar “o” Gmail MCP server no GitHub, o primeiro resultado por estrelas é justamente o que você deveria confiar menos, porque não tem mais ninguém revisando as dependências dele.

O modelo de auth é quem decide se isso é seguro

Todo servidor MCP do Workspace, oficial ou não, te coloca na frente das mesmas três decisões: de quem é o OAuth client, quais scopes, e single-user ou multi-user.

Use o seu próprio OAuth client, nunca um compartilhado. Os servidores oficiais do Google e o self-hosted querem um client ID e secret do seu próprio projeto do Google Cloud, não de um fornecedor terceiro. Esse client é a coisa que um atacante quer, e é a coisa que você consegue revogar sem tocar em mais nada.

Conceda scopes de leitura por padrão. O próprio guia de setup do Google adiciona gmail.readonly, drive.readonly, calendar.events.readonly e o equivalente pra todo outro produto antes de adicionar qualquer scope de escrita. Os scopes de escrita (gmail.compose, drive.file, documents) existem, e a lista de ferramentas do servidor MCP ainda é a segunda trava por trás deles: mesmo com gmail.compose concedido, o servidor oficial não tem nenhuma ferramenta que envia.

Single-user versus multi-user é uma decisão de deploy, não uma decisão de segurança. Os servidores oficiais do Google e o modo OAuth 2.1 PKCE do google_workspace_mcp deixam várias pessoas se autenticarem no mesmo servidor rodando, cada uma com o próprio token, isoladas umas das outras. Esse é o formato certo pra um time. Também são mais peças que podem dar problema do que a maioria dos setups individuais precisa. Se é só você e um cliente MCP, o fluxo single-user de “confidential client” tem menos coisa que pode quebrar.

Conectando uma fonte do Workspace no Hermes

O Hermes Agent recebe servidores MCP dentro de mcp_servers, em ~/.hermes/config.yaml. Um servidor do Workspace baseado em HTTP (o seu próprio deploy do google_workspace_mcp, ou os endpoints remotos do Google) entra por URL:

mcp_servers:
  workspace:
    url: "http://localhost:8000/mcp"
    trust: untrusted

trust: untrusted é a chave que mais importa aqui. Pela própria referência de config de MCP do Hermes, qualquer ferramenta num servidor untrusted que não tenha a anotação readOnlyHint: true exige aprovação pela superfície padrão de aprovação do Hermes antes de rodar, em qualquer plataforma de mensagem. Marque uma fonte do Workspace como untrusted e as leituras fluem normal, enquanto todo rascunho, mudança de rótulo ou criação de evento para e pergunta antes, não importa como o próprio servidor descreve as suas ferramentas.

A mesma coisa pela CLI, seguida de uma checagem antes de qualquer sessão ganhar acesso a isso:

Registre e teste o servidor no Hermes

1. Adicione o servidor

   $ hermes mcp add workspace --url "http://localhost:8000/mcp" --auth oauth

2. Conecte e liste as ferramentas dele

   $ hermes mcp test workspace

hermes mcp test conecta, lista as ferramentas descobertas, e sai com código de erro se a conexão ou a config estiver errada.

Conectando no Claude Code

A sintaxe atual do Claude Code, segundo a própria documentação da Anthropic, é claude mcp add --transport http <name> <url>, com um --header opcional pra um bearer token:

Registre o servidor no Claude Code

1. $ claude mcp add --transport http workspace http://localhost:8000/mcp

Isso bate exatamente com o README do próprio google_workspace_mcp: roda o servidor em modo HTTP, depois registra ele com esse único comando. Pros endpoints remotos oficiais do Google, o Claude.ai e o Claude Desktop pedem o client ID e secret do OAuth como um conector personalizado nas configurações deles, já que esses endpoints são hospedados pelo Google, não algo que você aponta com um comando local.

A plataforma não é a fonte

O Hermes tem um adaptador plugins/platforms/email: IMAP de entrada, SMTP de saída, configurado via platforms.email no config.yaml ou variáveis de ambiente EMAIL_*. Isso é um gateway. Ele deixa você falar com o Hermes mandando um email pra ele, do mesmo jeito que os gateways do Telegram ou do Slack deixam você falar com ele por um app de chat. Isso não tem nada a ver com Gmail MCP.

Um Gmail MCP server é uma fonte. Ele deixa o Hermes ler e agir na sua conta do Gmail como dado, do mesmo jeito que um servidor MCP do GitHub deixa ele ler issues. Um é como você alcança o agente. O outro é o que o agente consegue alcançar. Confundir os dois te deixa com um agente que não consegue agir na sua caixa de entrada de jeito nenhum, ou com um que consegue ler todo email que você tem mas que você nunca consegue mandar mensagem direto, e nenhum dos dois jeitos de falhar se anuncia até você ir procurar a peça que falta.

Onde isso entra num briefing diário

No meu trabalho, um cron job do Hermes escreve pra mim um briefing diário do que está acontecendo na empresa. Ele lê os servidores MCP da empresa pra Slack, Google Workspace, Git e Confluence ou Jira, e é organizado por seis sentidos: eu, eles, tendência, fronteira, comunidade, cliente. O Workspace é uma fonte entre várias ali, não o trabalho todo. Uma caixa de entrada te diz o que as pessoas estão pedindo, uma ferramenta de chat o que elas estão reagindo, um repositório o que de fato foi pro ar. Os sentidos são as perguntas. Cada um puxa de quaisquer fontes que respondam a essa pergunta, e o servidor MCP é a ponte entre a pergunta e o dado.

Antes de apontar um servidor MCP pra sua caixa de entrada

• ✓Obrigatório:
  Você criou o seu próprio OAuth client, não um compartilhado ou de fornecedor.Esse client é o que você revoga se algo der errado. Um client que você não controla é um client que você não consegue rotacionar.
• ✓Obrigatório:
  Você concedeu scopes de leitura primeiro, e scopes de escrita só se alguma ferramenta realmente precisar.gmail.readonly e gmail.compose, não mail.google.com. Confira a lista de scopes contra a lista de ferramentas, não contra o que parece seguro.
• ✓Obrigatório:
  As ferramentas com capacidade de escrita do servidor exigem aprovação, não só uma checagem de scope.trust: untrusted no Hermes, ou a trava de aprovação equivalente em qualquer coisa que rode o agente. Duas travas ganham de uma.
• ✓Obrigatório:
  Você checou quando o servidor fez o último commit.Número de estrelas é popularidade, não manutenção. Um Gmail MCP server arquivado com mil estrelas continua arquivado.
• ✓Obrigatório:
  Você sabe se o agente consegue enviar, não só ler e rascunhar.O Gmail MCP server do próprio Google não consegue enviar. Se o que você está usando consegue, isso é um passo deliberado pra um raio de explosão maior.

Google Workspace MCP e Gmail MCP, respostas rápidas

O que é MCP?+

MCP (Model Context Protocol) é o protocolo aberto que deixa um agente de IA, como o Claude Code ou o Hermes Agent, se conectar a uma ferramenta ou fonte de dados externa (Gmail, Drive, Calendar) através de um servidor MCP padronizado, em vez de uma integração feita na mão pra cada caso.

O que é o Google Workspace MCP?+

Não é um servidor só. O Google distribui os próprios servidores MCP remotos pra Gmail, Drive, Docs, Sheets, Slides, Calendar, Chat e People, com acesso fechado atrás do Developer Preview Program. Separadamente, servidores open source como o taylorwilsdon/google_workspace_mcp cobrem o mesmo terreno e mais, self-hosted, sem trava de acesso.

O que é o Gmail MCP server?+

O Gmail MCP server do próprio Google expõe nove ferramentas: buscar e ler threads, listar e criar rascunhos, e gerenciar rótulos. Não tem ferramenta de enviar e não tem ferramenta de deletar.

Servidores open source só de Gmail variam. Confira a lista de ferramentas e os scopes deles antes de assumir a mesma contenção.

O Google Workspace MCP é seguro?+

É tão seguro quanto o OAuth client, os scopes e a lista de ferramentas que você permitir. A própria documentação de setup do Google alerta sobre prompt injection indireta vinda de emails e documentos que o agente lê, e recomenda revisar toda ação. Scopes read-only e um tier de trust untrusted na config MCP transformam esse alerta numa trava real.

Dá pra usar o Gmail MCP com o Claude Code ou o Claude Desktop?+

Dá, de duas formas diferentes. O Claude Code registra qualquer servidor MCP HTTP com claude mcp add --transport http <name> <url>, o que funciona pra um servidor self-hosted como o google_workspace_mcp.

O Claude.ai e o Claude Desktop conectam no Gmail MCP server remoto oficial do Google como um conector personalizado, em Settings, Connectors, com o seu próprio client ID e secret do OAuth.

Como adicionar um servidor MCP do Google Workspace no Hermes Agent?+

Adicione uma entrada dentro de mcp_servers em ~/.hermes/config.yaml com uma url pra um servidor HTTP, ou use hermes mcp add <name> --url <endpoint> --auth oauth pela CLI. Configure trust: untrusted pra toda chamada de ferramenta com capacidade de escrita precisar de aprovação antes de rodar.