MCP (Model Context Protocol) é um protocolo aberto, publicado pela Anthropic em novembro de 2024, que padroniza a conversa entre um modelo de IA e ferramentas externas. Com ele, o Claude lê sua agenda, busca uma planilha no Drive, comenta uma issue no GitHub ou atualiza uma página do Notion sem que você copie e cole nada.
Protocolo, aqui, é um conjunto de regras que dois programas seguem para se entender, como o HTTP que faz qualquer navegador conversar com qualquer site. Este guia mostra o problema que o MCP resolve (o N×N de integrações), como programas se conectavam antes dele, quem faz o quê dentro do padrão e como habilitar servidores no Claude.ai e no Claude Code.
O diagrama acima resume a proposta inteira: em vez de um conector artesanal para cada par de sistemas, cada serviço publica um servidor MCP e qualquer cliente compatível conversa com todos eles. O restante do post explica como esse desenho funciona por dentro e como colocá-lo para rodar no seu ambiente.
Quer ligar o Claude nos sistemas que você já usa?
Na Imersão Claude Code para economistas, administradores e contadores você configura servidores MCP na prática e monta um fluxo em que o agente coleta dados, gera relatórios e conversa com os seus sistemas, com acompanhamento passo a passo.
O limite do Claude sem MCP
De fábrica, um agente como o Claude Code enxerga três coisas: os arquivos do projeto aberto, o terminal da máquina e o que você cola no chat. Esse alcance cobre bem o trabalho local, como ler um CSV, rodar um script ou montar um relatório.
O trabalho, porém, transborda essa caixa. O dado que você precisa está numa planilha do Google Drive que a equipe atualiza, a reunião está marcada no Google Calendar, a discussão sobre o relatório mora numa thread do Slack e o ticket do bug no pipeline do IPCA é uma issue no GitHub. Nada disso está visível para o modelo, porque ele não tem acesso à sua conta em nenhum desses serviços.
A saída habitual é você virar o intermediário: abrir cada ferramenta, copiar o trecho relevante, colar no chat, copiar a resposta e levá-la de volta. O agente fica limitado ao que você consegue transportar manualmente, e cada rodada dessa ponte consome minutos do seu dia.
O MCP corta esse vai e vem, mas a dor que ele trata é mais antiga que os modelos de linguagem. Conectar programas é um problema com décadas de história, e o protocolo fica mais claro quando você enxerga o que ele substitui.
Como programas se conectavam antes do MCP
Toda integração que parece automática é um programa conversando com outro: o Excel exporta o CSV que o Python lê, o Google Calendar dispara o lembrete por e-mail, o sistema de RH deposita o salário no banco. Três gerações de técnica sustentam essas conversas, e o MCP entra como a peça mais recente da linha.
Arquivos no meio do caminho
O jeito mais antigo, e ainda muito vivo, funciona por troca de arquivo: um programa escreve, outro lê. Você exporta a base de clientes em CSV, sobe num servidor, e o sistema do parceiro busca aquele arquivo de hora em hora. O método é simples e serve até hoje, mas exige que os dois lados combinem formato, nome e local do arquivo, e a atualização sempre carrega o atraso do horário marcado.
APIs: cada serviço com seu dialeto
A partir dos anos 2000, virou padrão cada serviço oferecer uma API (Application Programming Interface): um endereço na internet onde outros programas mandam pedidos por HTTP e recebem respostas em JSON, o formato de texto estruturado que virou língua franca da web. O Google Calendar tem API, o Slack tem, o GitHub tem, o Banco Central tem.
Cada API, no entanto, fala um dialeto próprio. O endpoint da Google difere do da Microsoft, a autenticação do Slack não se parece com a do GitHub e o formato das datas no Banco Central diverge do que o FRED publica. Conectar um sistema novo a uma API existente exige que alguém leia a documentação, descubra como pedir o token, mapeie os campos e trate os erros.
Para um par de sistemas, essa conta fecha: escreve-se um conector e segue-se em frente. O peso aparece quando o gráfico cresce, porque cada par exige seu próprio conector: três sistemas que conversam entre si pedem 3 conectores, cinco pedem 10 e vinte sistemas geram 190 pares possíveis. Esse crescimento tem nome no jargão de arquitetura: o N×N de integrações.
Function calling: a primeira ponte entre LLM e ferramentas
A partir de 2023, os modelos de linguagem ganharam o function calling: você descreve uma função para o modelo (nome, parâmetros, o que ela faz) e, quando convém, ele devolve um pedido para chamá-la em vez de responder só em texto. Foi a primeira ponte real entre LLM e sistemas externos, e provou que o modelo consegue acionar uma ferramenta.
O N×N, porém, ficou intacto. Um conector com a API do Notion escrito para o Claude não servia para o ChatGPT nem para o Cursor: mesma API, três (ou trinta) implementações paralelas, cada uma com seus bugs, cada uma refeita dentro do código de cada produto. Faltava um padrão, e o MCP entrou exatamente nessa lacuna.
O que é MCP, afinal
O Model Context Protocol define um jeito comum de um LLM conversar com ferramentas externas, trocando a multiplicação de conectores por uma soma. Um serviço como Notion, GitHub ou Drive implementa uma vez um servidor MCP, e qualquer cliente compatível com o protocolo usa aquele servidor sem código específico.
O paralelo do hardware ajuda: antes do USB, cada periférico vinha com cabo proprietário, com um formato para o mouse, outro para o teclado, outro para a impressora. Quando o USB pegou, o fabricante passou a seguir um padrão único que qualquer computador entende. O MCP cumpre esse papel para os modelos de linguagem.
Os três papéis do protocolo
O MCP define três peças que conversam entre si, e convém fixar os nomes porque eles aparecem nas mensagens de erro e nas telas de configuração:
- Host — o aplicativo que você usa: Claude Desktop, Claude Code, Cursor ou qualquer cliente que entenda MCP.
- Cliente MCP — o componente dentro do host que fala o protocolo, mantém a conexão com cada servidor e traduz pedidos e respostas.
- Servidor MCP — o programa que expõe as capacidades de um serviço externo (Notion, GitHub) na linguagem do protocolo.
O que um servidor MCP oferece
Um servidor expõe até três tipos de capacidade para o host e, por extensão, para o modelo:
🔧
📄
💬
Para quem está começando, tools é o conceito que carrega o protocolo, e a maioria dos servidores populares vive bem só com elas. O ganho aparece na prática: sem MCP, o modelo sabe o que entrou no treinamento (um estoque congelado, com data de corte) e o que você cola no chat; com MCP, ele opera sobre o estado atual dos seus sistemas, no momento da pergunta.
| Sem MCP | Com MCP | |
|---|---|---|
| Acesso aos dados | Só o que você cola na conversa | O estado atual do serviço, no momento da pergunta |
| Ações no mundo real | Nenhuma; o modelo só sugere o que fazer | Executa: cria issue, manda mensagem, edita documento |
| Quem mantém o conector | Cada aplicativo refaz o trabalho por conta | O serviço mantém um servidor que todos os clientes usam |
| Trocar de LLM | Refazer as integrações | Os mesmos servidores funcionam; o protocolo é aberto |
O que muda para o modelo com o protocolo. Elaborado por analisemacro.com.br.
Onde os servidores rodam
Um detalhe que costuma confundir no começo: o servidor MCP não vive numa nuvem central da Anthropic. Ele é um programa, e precisa estar rodando em algum lugar para o cliente conversar com ele. Dois cenários cobrem quase todos os casos.
No cenário local (stdio), o servidor é um comando que o próprio host inicia ao subir, como um pacote via npx ou um binário Python, e a conversa acontece pela entrada e saída padrão do processo. Ele roda na sua máquina, usa o seu disco e as suas credenciais, o que serve para acessar arquivos, um banco interno ou scripts seus.
No cenário remoto (HTTP), o servidor está hospedado pelo próprio provedor do serviço, com endereço público, e o cliente se conecta pela internet. A autenticação usa OAuth, o fluxo em que você autoriza o acesso na página do próprio serviço, sem entregar senha nem token ao aplicativo. Notion, GitHub, Linear e Asana já oferecem servidores remotos oficiais: você cola a URL e autoriza.
Na prática, o remoto exige menos de você (nada para instalar, atualizações automáticas do lado do provedor), enquanto o local é o caminho para o que não faria sentido na nuvem, como ler os seus arquivos ou consultar um banco interno da empresa.
MCP no Claude.ai: os connectors
A porta de entrada mais simples é o chat na web, que aceita servidores remotos pelo menu de Connectors. O caminho tem quatro passos: abrir Settings → Connectors no menu do perfil, colar a URL do servidor em Add custom connector, autorizar o acesso na aba que abre no site do serviço e voltar ao chat, onde o connector aparece pronto para uso em linguagem natural ("liste minhas páginas no Notion que mencionam IPCA").
O passo da autorização merece uma olhada por dentro, porque é onde mora a segurança do fluxo. Você nunca cola token nem senha no Claude: o serviço mostra a tela de permissões, você aprova os escopos (leitura, escrita) e um token de acesso volta para o Claude por baixo dos panos.
A partir daí o agente chama a API do serviço identificado como você, dentro dos escopos aprovados. Se você revogar o acesso no painel do serviço, o connector deixa de funcionar na hora, já que é o serviço quem decide se honra o token.
MCP no Claude Code: escopos, comando e .mcp.json
No Claude Code o conceito é o mesmo, mas a configuração vive no terminal e em arquivos do projeto. Um servidor pode ser registrado em três escopos: local (vale só para o projeto atual, na sua máquina, bom para experimentos), project (entra num arquivo versionado e vale para todo o time) e user (vale para qualquer projeto que você abrir, útil para servidores genéricos como o do GitHub).
O comando central é o claude mcp add, documentado na página de MCP do Claude Code. Para um servidor remoto, uma linha resolve:
claude mcp add --transport http notion https://mcp.notion.com/mcp
Aí estão o tipo de transporte (http para remoto; o padrão é stdio, para local), o apelido que aparecerá nas listagens (notion) e o endereço do servidor. Servidores que exigem autenticação iniciam o OAuth na primeira chamada, e o token fica guardado entre sessões. No escopo project, a configuração entra num .mcp.json na raiz do repositório:
{
"mcpServers": {
"github": { "transport": "http", "url": "https://api.githubcopilot.com/mcp" }
}
}
Esse arquivo é seguro para commitar, porque só descreve URLs e nomes, sem credenciais: cada pessoa do time autoriza com o seu próprio OAuth ao abrir o projeto. Assim a decisão "este projeto usa GitHub via MCP" fica versionada junto com o código, e quem clonar o repositório recebe a mesma integração depois de uma confirmação.
A conversa com o servidor ligado
Com o servidor configurado, o uso não exige sintaxe nova. Você fala em português sobre o trabalho, o Claude enxerga a lista de ferramentas disponíveis e decide quando invocar uma delas, pedindo a sua confirmação antes de executar.
O nível de confirmação é configurável, e a regra prática distingue leitura de escrita: para ferramentas que só consultam dados (buscar issue, ler página do Notion), liberar de vez acelera o fluxo; para as que escrevem (fechar issue, mandar mensagem, editar documento), vale manter a aprovação manual até você conhecer o padrão de chamadas que o agente propõe.
Quando MCP vale a pena e quando é exagero
Habilitar um servidor cobra atenção, manutenção e cuidado de segurança, e nem todo trabalho compensa essa conta. A tabela resume os critérios:
| Faz sentido usar MCP quando… | É exagero quando… |
|---|---|
| Você precisa de dado vivo de um serviço (Notion, calendário, banco) | O dado já está num CSV ou num script do projeto |
| A tarefa exige uma ação no mundo (criar PR, mandar mensagem, atualizar ticket) | Você só quer explicação de código ou refactor local |
| A integração será reusada em vários projetos ou pela equipe | É uma consulta única, feita uma vez no ano |
| Há servidor oficial mantido pelo provedor do serviço | Você teria que escrever o servidor e o ganho é marginal |
Critérios para decidir se um servidor entra no seu ambiente. Elaborado por analisemacro.com.br.
Para fluxos de análise dentro de um projeto local, como ler CSVs, rodar R ou Python e gerar relatórios em Quarto, o Claude Code já entrega tudo nativamente. O protocolo entra em cena quando o trabalho cruza a fronteira do projeto e envolve outras pessoas, outros sistemas e outros dados.
Cuidados práticos
Conectar o Claude ao seu Notion, calendário e GitHub multiplica o que ele consegue fazer, e também o que ele consegue estragar. Cinco atitudes poupam dor de cabeça:
- Comece pelos servidores oficiais. Notion, GitHub, Linear e Asana mantêm servidores próprios, hospedados por eles, com OAuth nativo. Servidores de terceiros funcionam, mas exigem confiança no autor: leia o código antes de instalar.
- Use escopos mínimos no OAuth. Para experimentar, prefira permissões só de leitura; suba para escrita quando precisar, porque em alguns serviços a volta atrás dá trabalho.
- Versione no
.mcp.jsonsó servidores oficiais. Servidores customizados ou em teste ficam melhor nos escopos local ou user, até valerem para todo o time. - Leia a primeira chamada de cada ferramenta. O Claude Code mostra o que será enviado ao servidor antes de executar, e as primeiras invocações revelam o padrão do que o agente costuma propor.
- Revogue o acesso ao trocar de máquina ou sair de um time. O token continua válido até alguém apagá-lo no painel do serviço.
Um lembrete de contexto: o MCP é um protocolo jovem, e tanto a especificação quanto os servidores evoluem rápido, com ferramentas aparecendo e mensagens de erro mudando. Quando algo não funciona como descrito, a documentação do servidor específico costuma responder antes de qualquer caça a bug no Claude.
Considerações finais
APIs existem há décadas e o function calling existe desde 2023, então nada do que o MCP faz era tecnicamente impossível antes. A contribuição do protocolo é cortar o N×N: cada serviço mantém um servidor padronizado, cada cliente compatível fala com ele sem código específico, e a manutenção pesa do lado do serviço.
Para quem usa, o efeito é o agente deixar de ser um leitor de arquivos solto no projeto e passar a operar sobre os sistemas onde o trabalho acontece: abrir tickets, comentar pull requests, atualizar páginas e responder com base no que está lá agora. O ciclo de abrir dez abas, copiar de uma e colar na outra dá lugar a uma conversa só, e o ganho se traduz de forma diferente em cada mesa:
- Economistas: o agente consulta a planilha de acompanhamento no Drive, cruza com as séries do projeto e abre a issue do pipeline no GitHub, sem que o dado passe pelo seu ctrl+C.
- Administradores: agenda, quadros de tarefas e documentos de gestão (Calendar, Notion, Asana) viram fontes que o agente lê e atualiza, e o relatório de status sai da conversa em vez de sair de quatro abas.
- Contadores: planilhas de clientes no Drive, prazos no calendário e pendências em sistemas de tickets entram no mesmo fluxo, com o agente conferindo e registrando sob sua aprovação a cada escrita.
O caminho de adoção cabe em meia hora: escolher os dois ou três serviços mais presentes no seu dia (GitHub, Notion, Drive), habilitar os servidores oficiais com permissões de leitura e testar as primeiras conversas. Da leitura para a escrita, e do experimento para o .mcp.json do time, o nível de acesso cresce junto com a confiança.
Do protocolo ao agente rodando no seu trabalho
Você viu o que o MCP faz; o passo seguinte é configurar os servidores, montar o projeto e colocar um agente para trabalhar com os seus dados. É isso que a Imersão Claude Code para economistas, administradores e contadores ensina, da instalação ao fluxo completo. Quem quer acesso a todos os cursos e formações da casa tem o AM Black, a assinatura anual.
Leia também:
