MCP para times de dados: o que é e como usar com segurança
Entenda o que é MCP, como assistentes de IA trabalham nos seus pipelines de dados e o checklist de segurança antes de conectar um agente.

O job do HubSpot falhou ontem à noite. Você encontra a execução na ferramenta de pipeline, copia o log de erro, cola no Claude ou no Cursor e adiciona à mão mais algumas informações, como qual conexão foi usada, o que mudou ontem, como é a tabela etc. O assistente devolve uma resposta que, na melhor das hipóteses, é um bom palpite, porque ele não conhece o sistema.
O MCP (Model Context Protocol) permite que o assistente trabalhe com a ferramenta, então ele consegue encontrar a execução que falhou, ler os logs e agir sobre eles. Mas isso levanta uma nova pergunta para os times de dados. Se o agente pode alterar pipelines, como decidir o que ele tem permissão para fazer?
O que é MCP?
O MCP é um padrão aberto para conectar aplicações de IA a outros sistemas. Ele oferece uma forma de assistentes como Claude, Cursor e VS Code acessarem contexto e executarem ações em várias ferramentas.
A documentação oficial descreve o MCP como uma porta USB-C para aplicações de IA. Isso significa que, desde que um assistente suporte MCP, ele pode se conectar a qualquer ferramenta que tenha um servidor MCP, sem que ninguém precise construir integrações sob medida para cada par de ferramenta e assistente.
Uma integração MCP tem três partes:
- Host: é a aplicação de IA que você já usa, como o VS Code ou o Claude.
- Cliente: é um pequeno programa conector que roda dentro do host. O host abre um cliente separado para cada servidor com o qual quer conversar.
- Servidor: é um programa oferecido por uma ferramenta, que diz ao assistente o que ele pode ler e fazer nessa ferramenta.
Por exemplo, digamos que você adicionou ao VS Code o servidor MCP da sua plataforma de pipelines. O VS Code é o host e vai abrir um cliente para esse servidor. Quando você pergunta "quais execuções falharam hoje?", o modelo escolhe a ação "listar execuções" oferecida pelo servidor, e o cliente envia o pedido ao servidor, que responde com a lista de execuções.
Um servidor pode oferecer três tipos de funcionalidade:
- Tools (ferramentas): são ações que o assistente pode disparar, como iniciar uma sincronização.
- Resources (recursos): dão contexto adicional ao assistente, como o log de uma execução.
- Prompts: são modelos prontos que podem ser usados para pedidos comuns.
Os servidores podem rodar no seu próprio computador ou como um serviço remoto. Um servidor local se comunica com o host pela entrada e saída padrão. Um servidor remoto se comunica por HTTP, e a especificação do MCP sugere OAuth como método de autenticação preferido, para que os usuários façam login pelo navegador em vez de copiar e colar uma chave.
Em 25 de novembro de 2024, a Anthropic anunciou que havia aberto o código do MCP, junto com os primeiros servidores para integrar Google Drive, Slack, GitHub, Postgres etc. Em dezembro de 2025, a Anthropic transferiu o protocolo para a Agentic AI Foundation, um fundo da Linux Foundation criado por Anthropic, Block e OpenAI, com apoio de Google, Microsoft e AWS.
Por que isso importa para times de dados: o ciclo do copiar e colar
Imagine que você é engenheiro de dados e acabou de receber um alerta sobre um pipeline que falhou ontem à noite. Seu fluxo de trabalho típico deve ser parecido com este:
- Abrir a ferramenta de pipeline depois de receber o alerta
- Encontrar a execução que falhou entre as execuções da noite anterior
- Copiar o log de erro e o ID do job ou da execução
- Colar o erro na janela de chat da IA
- Adicionar à mão detalhes como o nome da fonte, mudanças de schema ou no app de origem desde ontem e a configuração do job
- Por fim, aplicar a correção manualmente de volta na ferramenta
Nesse cenário, você fica pulando entre várias janelas, e o assistente só sabe o que você copiou e colou. Se você não der detalhes suficientes (por exemplo, as configurações de sincronização ou a última execução bem-sucedida), ele vai dar uma resposta bem genérica, que serviria para qualquer pipeline.
Segundo a própria documentação do Claude, conectar um servidor MCP é útil quando você tem dados em outras ferramentas que copiaria para o chat. Conectar o servidor permite que o assistente leia e execute ações diretamente nesse sistema.
O que um agente pode fazer dentro da Erathos
O servidor MCP da Erathos permite usar o assistente de IA que você já usa (Claude, Cursor, Codex, VS Code) para gerenciar o seu workspace da Erathos por meio de uma conversa.
Seu assistente pode fazer o seguinte no seu workspace da Erathos:
- Analisar falhas: ele consegue obter mais contexto sobre uma execução que falhou, como logs, linha do tempo e métricas das tabelas sincronizadas. Isso evita que você precise copiar os logs de uma execução com falha na tela de histórico de execuções.
- Criar conexões: peça à IA para criar uma nova conexão de HubSpot ou Postgres na Erathos, e ela cuida da criação da conexão. Você ou outra pessoa do time adiciona as credenciais na plataforma da Erathos (fora do chat).
- Configurar jobs: diga à IA quão atualizados seus dados precisam estar e se você quer a versão mais recente das linhas ou o histórico de mudanças. A IA faz as escolhas necessárias nas configurações do job e mostra uma prévia antes de salvar.
- Orquestrar ações seguintes: a Erathos pode disparar outras ferramentas, como DAGs do Airflow ou jobs do dbt Cloud, depois que um job ou uma conexão termina de sincronizar. A IA consegue gerenciar os gatilhos e as regras para rodar essas ações seguintes e verificar o que o gatilho fez depois que a execução termina. Observação: isso exige um plano com orquestração.
A IA pode trabalhar com as fontes de dados que você já usa, como HubSpot e PostgreSQL, já que a Erathos tem mais de 100 conectores.
O processo como um todo fica assim:
Permissões e controle
O modelo deve decidir o que fazer. As suas permissões devem decidir o que o modelo pode fazer. Identidade, permissões e controle de acesso são importantes demais para serem delegados a um modelo de linguagem que pode errar ou ser enganado.
A especificação do MCP incorpora isso na forma como define as tools. As tools no MCP são feitas para serem controladas pelo modelo, ou seja, o modelo decide qual tool chamar. A especificação também diz que deve haver uma pessoa no processo, com a possibilidade de negar qualquer chamada de tool. Por fim, os servidores devem validar as entradas e aplicar os demais controles de acesso do lado deles, onde ficam fora do controle do modelo.
A Erathos faz isso de três formas:
- As mesmas permissões que você. O agente só age nos workspaces que a sua própria conta da Erathos já alcança. A Erathos verifica cada chamada de tool contra as suas permissões reais, ao vivo, a cada pedido. Cada ação indica um único workspace, e nada recorre ao "workspace atual" por padrão.
- Nenhuma credencial no chat. O agente cria uma conexão, mas nunca recebe a senha ou a chave de API. Uma pessoa digita essas informações na plataforma da Erathos. Se quem tem a senha do banco não tiver conta na Erathos, o agente pode gerar um link seguro de uso único para essa pessoa, que expira em 24 horas por padrão. Quando um gatilho para outra ferramenta precisa de um token, o agente se refere a um segredo salvo pelo nome, e a Erathos nunca mostra o valor dos segredos, nem aqui nem em nenhum outro lugar.
- Uma prévia antes de salvar. As mudanças mostram uma prévia primeiro. Nas configurações de job, o agente faz um dry run (simulação) por padrão. A Erathos envia a mudança pelo mesmo processo de salvamento usado na sua própria página de gerenciamento de jobs e depois desfaz, então a prévia mostra exatamente o que aconteceria.
A prévia do job ajuda a identificar problemas que passariam despercebidos com facilidade, como uma mudança de cursor (ou seja, o marcador de onde uma sincronização parou) que vai disparar a recarga de todo o histórico de uma tabela. Ela também avisa se você passaria do limite de jobs do seu plano.
Este diagrama mostra como um pedido passa por essas verificações.
O que pode dar errado com servidores MCP
A principal ameaça ao MCP é a prompt injection, quando o agente lê um texto vindo de uma ferramenta e executa as instruções contidas nele. Houve dois casos públicos disso em 2025:
- GitHub, maio de 2025. Uma issue maliciosa em um repositório público sequestrou o agente de um usuário por meio do servidor MCP do GitHub. O agente então vazou dados dos repositórios privados do usuário em um pull request público. O Claude Desktop pede, por padrão, que o usuário confirme cada chamada de tool, mas muitos usuários escolhem "Always Allow" (sempre permitir) e deixam de prestar atenção. Os pesquisadores não encontraram nenhum bug no código do servidor, apenas um problema na forma como o agente, o acesso dele e o texto não confiável interagiram.
- Supabase, julho de 2025. Um agente no Cursor usou o servidor MCP da Supabase com uma chave que ignora toda a segurança em nível de linha. O agente leu tickets de suporte de clientes, e um deles continha instruções escondidas para extrair dados privados.
Simon Willison chama isso de "trifeta letal": acesso a dados privados, exposição a conteúdo que pode conter instruções e a capacidade de enviar dados para fora. Um agente com os três pode ser induzido a vazar dados.
Quebrar a trifeta interrompe o ataque. Um modo somente leitura tira do agente a capacidade de enviar dados para fora. Por isso a Supabase sugere um modo somente leitura e limitado ao projeto.
Ferramentas de pipeline estão cheias de conteúdo escrito por outras pessoas: mensagens de erro de APIs de origem, nomes de campos e tickets de suporte. Isso significa que as mesmas regras valem para um stack de dados.
Um checklist para qualquer servidor MCP
Antes de conectar um agente a qualquer ferramenta de dados, estas são as perguntas a fazer sobre o servidor MCP dela e sobre o seu assistente:
Verificação | O que perguntar | Como a Erathos lida com isso |
|---|---|---|
Permissões limitadas | O agente age com as suas próprias permissões, e só com elas? Evite servidores que pedem uma chave com acesso total. | Cada chamada é verificada ao vivo contra as permissões da sua conta na Erathos, um workspace por vez. |
Nenhuma exposição de credenciais | O agente chega a ver senhas, chaves ou tokens? Dá para fazer login sem colar uma chave? | Você faz login com OAuth. As credenciais vão para a plataforma, nunca para o chat, e o valor dos segredos nunca é exibido. |
Prévia antes de gravar | O servidor mostra o que uma mudança vai fazer antes de salvar? Seu assistente pergunta antes de rodar uma tool? | As mudanças mostram uma prévia primeiro. As configurações de job rodam como dry run por padrão. |
Trilha de auditoria | Dá para ver depois quem fez o quê? | Cada execução registra o e-mail do usuário que a iniciou. |
Começar só com leitura | Dá para começar lendo e adicionar gravações depois? | Diagnosticar uma execução com falha e listar jobs só leem dados. |
Texto não confiável | O agente lê conteúdo vindo de fora do seu time? | Logs de erro de APIs de origem vêm de fora, então mantenha os pedidos de aprovação ativos para gravações. |
A outra metade do controle está no que o assistente faz. Cada um destes assistentes tem alguma forma de pedir confirmação antes de executar uma tool MCP.
O Claude Code permite limitar os escopos de OAuth concedidos a um servidor, e as organizações também podem configurar as tools dos conectores como "perguntar" ou "bloqueada". O Cursor, por padrão, pede aprovação antes de usar tools MCP, e cada chamada pode ser expandida para ver os argumentos. O Codex tem um modo de aprovação writes, que pergunta antes de executar qualquer tool que não esteja marcada como somente leitura. O VS Code avisa que as tools podem acessar serviços externos com as suas permissões, e os usuários podem expandir a primeira chamada de qualquer tool para conferi-la.
Esses pedidos de confirmação só ajudam enquanto você os lê. No caso do GitHub, os ataques começaram com usuários que clicaram em "Always Allow" nesses avisos.
Conecte a Erathos ao seu assistente
A Erathos oferece um servidor MCP remoto em https://mcp.erathos.com/mcp que faz o login via OAuth na sua conta da Erathos, sem nenhuma chave de API.
Claude Code. Adicione o servidor, faça login e confira o status:
claude mcp add --transport http erathos https://mcp.erathos.com/mcp
claude mcp login erathosclaude mcp get erathos
Claude Desktop e claude.ai. Em Settings, escolha Connectors, selecione Add custom connector e cole a URL do servidor. Nos planos Team e Enterprise, o conector é adicionado uma única vez por um owner em Organization settings, e os membros clicam em Connect.
Codex. Adicione isto ao ~/.codex/config.toml e depois rode codex mcp login erathos:
[mcp_servers.erathos]url = "https://mcp.erathos.com/mcp"auth = "oauth"
Cursor. Adicione isto ao ~/.cursor/mcp.json, ou ao .cursor/mcp.json de um projeto:
{ "mcpServers": { "erathos": { "url": "https://mcp.erathos.com/mcp" } }}
VS Code. Rode "MCP: Add Server" na Command Palette, escolha HTTP e cole a URL. Você também pode adicionar ao mcp.json:
{ "servers": { "erathos": { "type": "http", "url": "https://mcp.erathos.com/mcp" } }}
Você também pode conectar outros assistentes que suportem servidores MCP remotos com OAuth. Como primeiro pedido, experimente pedir ao assistente que liste os seus workspaces.
Exemplos de prompts para engenheiros de dados
Estes prompts vão de operações de leitura a operações de gravação. O primeiro grupo não exige nenhuma mudança no seu workspace e pode ser usado como está:
- "Quais execuções falharam hoje?"
- "Por que o job do HubSpot falhou ontem à noite? Me mostre o log completo e a linha do tempo."
- "Quais jobs não sincronizaram com sucesso na última semana?"
- "Quais schemas o nosso banco Postgres tem, e qual o tamanho deles?"
Os próximos prompts fazem mudanças no seu workspace, então cada um vem com uma prévia ou com uma etapa para uma pessoa:
- "Crie uma conexão para o nosso banco Postgres de produção e sincronize a tabela orders a cada hora." Depois que o agente cria a conexão, você insere as credenciais na Erathos, e o agente mostra as configurações do job antes de salvá-las.
- "Crie um link que eu possa mandar para o nosso DBA inserir as credenciais do Postgres."
- "Rode de novo o job de orders com um full refresh."
- "Depois que o job de orders sincronizar, inicie o nosso job do dbt Cloud, mas só quando linhas tiverem sido carregadas."
Perguntas frequentes
O MCP é seguro para dados de produção?
A segurança do MCP é tão forte quanto as permissões do servidor e a sua forma de dar aprovações. Um servidor que valida as suas permissões a cada pedido, não guarda credenciais no chat e mostra uma prévia das operações de gravação ajuda a conter o estrago de um agente que erra ou é enganado. Uma chave com acesso total usada com "Always Allow" ativado não ajuda.
O agente vê os meus dados?
O agente vê tudo o que as tools do servidor devolvem. No caso da Erathos, isso inclui itens como workspaces, conexões, jobs, logs de execução, contagem de linhas e nomes de tabelas e colunas (mas nunca credenciais ou valores de segredos). A saída das tools faz parte da conversa, então trate coisas como logs de execução como você trataria qualquer outra coisa que cola em um chat.
Quais assistentes suportam MCP?
Servidores MCP (locais e remotos) são suportados por muitas ferramentas, como Claude Code, Cursor, Codex e VS Code. O servidor MCP da Erathos é compatível com qualquer ferramenta que suporte servidores MCP remotos com OAuth.
Preciso escrever código?
Não. No Claude Desktop, basta colar uma URL nas configurações. No Cursor, no Codex e no VS Code, você adiciona algumas linhas de configuração ou usa um comando de menu e depois faz login pelo navegador. A partir daí, é só conversar em linguagem natural.
Teste nos seus próprios pipelines
Se você usa um assistente, pode conectar o servidor MCP da Erathos a ele. Depois, é só perguntar sobre as execuções de ontem à noite. Teste a Erathos grátis por 14 dias.