1 Onde o Claude esbarra (e por que MCP existe)
Em vários momentos você usou o Claude Code para ler arquivos, rodar scripts e montar relatórios em Quarto — sempre dentro de um projeto, na sua máquina, com as ferramentas que o agente já traz de fábrica: edição de arquivo, terminal e busca no repositório.
Em algum momento o trabalho transborda essa caixa. O dado que você precisa não está num CSV local, está numa planilha do Google Drive que a equipe atualiza. A reunião com a coordenação está marcada no Google Calendar e ninguém anotou no projeto. A discussão sobre o relatório de novembro mora numa thread do Slack, e o ticket do bug no pipeline do IPCA é uma issue no GitHub.
O Claude, sozinho, não enxerga nada disso, porque não tem acesso ao seu calendário nem à sua pasta no Drive. Quando você pede “olha lá no Notion o que ficou combinado”, a resposta é uma impossibilidade gentil, e a saída acaba sendo você mesmo abrir cada ferramenta, copiar o conteúdo relevante e colar de volta no chat.
Antes de mostrar como ligar, convém entender por que o problema é mais antigo que LLM. A dor de conectar programas vem de décadas atrás, e o MCP só faz sentido quando você enxerga o que ele substitui.
2 Como aplicativos se conectavam antes do MCP
O Excel exporta para CSV, que o Python lê, que cospe um gráfico que vai parar num slide do PowerPoint. O Google Calendar dispara lembrete por e-mail, o sistema de RH manda o salário no banco — toda integração que parece automática é, no fundo, um programa conversando com outro, e existem três jeitos clássicos de fazer essa conversa acontecer, com o MCP entrando como a peça mais recente da linha.
2.1 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 ERP do parceiro busca aquele CSV de hora em hora. Funciona e é simples, mas só serve quando os dois lados combinam formato, nome e local do arquivo, e a atualização sempre carrega o atraso do horário marcado.
2.2 APIs: o jeito moderno, programa a programa
A partir dos anos 2000, virou padrão cada serviço oferecer uma API (Application Programming Interface), um endereço onde outros programas mandam pedido por HTTP e recebem resposta em JSON. O Google Calendar tem API, o Slack tem, o GitHub tem, o BCB tem. Você (ou seu script) faz uma requisição e recebe os dados estruturados na hora.
O problema é que cada API fala um dialeto. O endpoint da Google difere do da Microsoft, a autenticação do Slack não se parece com a do GitHub, os nomes dos campos no Notion são outros e o formato das datas no BCB diverge do que o FRED publica. Para conectar um sistema novo a uma API existente, alguém precisa ler a documentação, descobrir como pedir o token, mapear os campos e tratar os erros.
Quando você conecta um sistema a outro, a conta fecha: escreve um conector e segue. O peso aparece quando o gráfico fica mais cheio, porque três sistemas que conversam entre si já exigem três pares de conectores, e vinte sistemas no diagrama produzem cento e noventa pares possíveis.
2.3 A primeira vez que LLM tentou se conectar: function calling
A partir de 2023, os modelos passaram a oferecer function calling: você descreve uma função (nome, parâmetros, o que ela faz) e, quando convém, o modelo retorna o pedido para chamá-la, em vez de só responder em texto. Foi a primeira ponte real entre LLM e ferramentas externas, e resolveu o conceito — o modelo de fato consegue acionar um sistema.
O problema do N×N, porém, ficou intacto. Cada aplicativo que quisesse oferecer Google Calendar precisava reimplementar a integração com a Google, e cada plataforma que oferecesse Slack repetia o mesmo trabalho do vizinho. O conector existia, só que dentro do código de cada produto, sem padrão entre eles.
3 O que é MCP, afinal
O Model Context Protocol é um protocolo aberto, publicado pela Anthropic em novembro de 2024, que define um jeito comum de um LLM conversar com ferramentas externas. Em vez da multiplicação de conectores, uma soma:
- Um serviço (Notion, GitHub, Drive) implementa uma vez um servidor MCP.
- Qualquer LLM compatível com MCP (Claude e outros que adotem o padrão) consegue usar aquele servidor sem código específico.
Para quem está acostumado com hardware, o paralelo é o USB. Antes dele, cada periférico vinha com seu cabo proprietário — mouse, teclado, impressora, scanner —, cada um com formato próprio. Quando o USB pegou, virou conector único: o fabricante segue o padrão e qualquer computador entende. MCP cumpre esse papel para LLMs.
3.1 Os três papéis no 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 configurações:
- 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.
3.2 O que um servidor MCP oferece
Um servidor expõe três tipos de coisa para o host e, por extensão, para o LLM:
- Tools (ferramentas) — ações que o modelo pode executar: criar issue, mandar mensagem no Slack, ler célula da planilha, rodar query no banco. Equivale ao function calling, porém padronizado.
- Resources (recursos) — conteúdo que o modelo pode ler como contexto: o texto de um documento, o resultado de uma consulta, um arquivo. Não executa nada, só fornece dados.
- Prompts — modelos de instrução prontos, que o servidor sugere ao host para uso comum.
Para quem está começando, tools é o conceito principal. Resources e prompts aparecem em casos mais específicos, e a maioria dos servidores populares vive bem só com tools.
3.3 O ganho concreto para o modelo
Sem MCP, o que o modelo sabe se limita a duas coisas: o que entrou no treinamento (estoque congelado, com data de corte) e o que você cola no chat (precisa colar a cada vez). O resto fica em vácuo.
Com MCP, o modelo passa a operar sobre o estado atual dos seus sistemas. A pergunta “qual ticket está aberto sobre o pipeline do IPCA?” deixa de exigir cópia manual, porque o servidor MCP do GitHub responde no momento da pergunta com o que há lá agora. O agente, antes confinado ao texto, passa a ler dados vivos, comparar com o que está no projeto e executar ações sobre os sistemas.
| 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 — só sugere o que você deveria fazer | Executa: cria issue, manda mensagem, edita documento |
| Quem mantém o conector | Cada app refaz o trabalho por conta | O serviço mantém um servidor que todos os clientes usam |
| Trocar de LLM | Refazer integrações | Mesmos servidores funcionam — o protocolo é aberto |
4 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 esse programa precisa estar rodando em algum lugar para o cliente conversar com ele. Há dois cenários comuns.
- Local (stdio) — o servidor é um comando que o próprio host inicia ao subir, como
npx algum-servidor-mcpou um binário Python. A conversa acontece pela entrada e saída padrão do processo (standard input/output), e isso serve para acessar coisas da sua máquina: o sistema de arquivos, um banco local, um script seu. Roda no seu computador, usa seu disco e suas credenciais. - Remoto (HTTP) — o servidor está hospedado pelo próprio provedor do serviço, com endereço público. O cliente do Claude se conecta via HTTP e o serviço cuida da autenticação no fluxo. A maioria dos servidores oficiais grandes (Notion, GitHub, Linear, Asana) já oferece versão remota: você só cola a URL e autoriza.
Na prática, o remoto exige menos da sua máquina (nada para instalar localmente) e pega atualizações sem você reiniciar nada, mas depende da disponibilidade do serviço. O local dá controle total, principalmente para coisas que não fariam sentido na nuvem, como ler arquivos seus ou falar com um banco interno.
5 MCP no Claude.ai (o chat web)
A interface mais simples para experimentar MCP é o Claude.ai — o chat na web. Ele aceita servidores remotos configurados a partir do menu de Connectors.
5.1 Caminho geral
O fluxo é o mesmo para qualquer servidor oficial remoto:
Os passos detalhados:
- Abrir
claude.ai, clicar no avatar e ir em Settings → Connectors. - Em Add custom connector, colar a URL do servidor remoto do serviço (para o Notion, por exemplo,
https://mcp.notion.com/mcp). - Clicar em conectar. Uma nova aba abre na página do serviço (Notion, GitHub, Linear) pedindo para você autorizar o acesso — é o fluxo OAuth, e você não cola token nenhum no Claude, porque o serviço entrega um token interno depois que você aprova.
- Voltar ao chat. O connector aparece com um ícone e o modelo já pode usá-lo numa conversa, com naturalidade: “liste minhas páginas no Notion que mencionam IPCA”.
Dica:
Cada serviço grande publica a URL oficial do seu servidor MCP na própria documentação. Os mais comuns para quem trabalha com dados: Notion, GitHub, Linear, Asana, Atlassian (Jira/Confluence), Cloudflare, Stripe. A Anthropic mantém um diretório no site oficial.
5.2 O fluxo de autorização por dentro
Convém abrir a caixa-preta do clique. Quando você manda conectar:
A partir desse ponto, o agente passa a chamar a API do serviço autenticado como você, dentro dos escopos que você aprovou. Se você revogar o acesso no painel do serviço (Notion, GitHub etc.), o connector para de funcionar, porque não é o Claude quem guarda a senha — é o serviço quem decide se honra o token.
6 MCP no Claude Code
No Claude Code o conceito é o mesmo, mas a configuração vive no terminal e em arquivos de projeto. Há três níveis em que você pode ligar um servidor:
- Local — vale só para o projeto atual, só na sua máquina. Bom para experimento isolado.
- Project — vale para todos que abrirem o projeto, porque a configuração entra num arquivo
.mcp.jsonna raiz, que vai para o git, e toda a equipe enxerga os mesmos servidores. - User — vale para qualquer projeto que você abrir naquela máquina, e cabe bem para servidores genéricos como GitHub, que você sempre quer ter à mão.
6.1 Adicionando um servidor
O comando central é claude mcp add. A forma mínima para um servidor remoto:
claude mcp add --transport http notion https://mcp.notion.com/mcpO que cada parte significa:
--transport http— diz que é um servidor remoto via HTTP (o padrão é stdio, para servidores locais).notion— apelido que você dá, e que vai aparecer nas listagens e nas confirmações.https://mcp.notion.com/mcp— endereço do servidor remoto.
Sem a flag --scope, o servidor entra no escopo local (só este projeto, só você). Para subir o escopo:
claude mcp add --scope user --transport http notion https://mcp.notion.com/mcpPara servidor local (stdio), o comando é semelhante, mas sem --transport. Exemplo de um servidor de sistema de arquivos rodando via npx:
claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /caminho/da/pastaO -- separa o que é argumento do claude mcp add do que é o comando para iniciar o servidor.
6.2 Os comandos do dia-a-dia
| Comando | O que faz |
|---|---|
claude mcp list |
Lista os servidores configurados e o status de cada um (conectado, falhou, autenticando) |
claude mcp get <nome> |
Mostra os detalhes (URL, escopo, transporte) de um servidor específico |
claude mcp remove <nome> |
Remove um servidor do escopo onde está |
/mcp (dentro do chat) |
Painel interativo: status, ferramentas disponíveis, fluxo de autenticação |
6.3 O arquivo .mcp.json (escopo project)
Quando você adiciona um servidor com --scope project, o Claude Code cria ou edita um arquivo .mcp.json na raiz do repositório. Ele tem a cara de uma configuração simples:
"mcpServers": {
"github": {
"transport": "http",
"url": "https://api.githubcopilot.com/mcp"
}
}
}
Por estar no repositório, qualquer pessoa que abrir aquele projeto no Claude Code recebe a sugestão de habilitar o servidor e, depois de uma confirmação, passa a contar com a mesma integração que você. Esse é o caminho recomendado para projetos compartilhados: o time configura uma vez, e o conhecimento de “este projeto usa GitHub via MCP” fica versionado junto com o código.
.mcp.json é seguro para commitar — ele só descreve URLs e nomes, sem credenciais. As autorizações continuam por usuário (OAuth pessoal). Nunca cole token de API no JSON; servidores que dependem de chave própria oferecem variáveis de ambiente ou prompt na primeira execução.7 Usando o servidor numa conversa
Com o servidor configurado, o uso não exige sintaxe nova: o Claude vê a lista de ferramentas disponíveis e decide quando faz sentido invocar uma, enquanto você fala em português natural sobre o trabalho.
Quando o agente decide chamar uma ferramenta, ele primeiro pede confirmação, e você vê na tela algo como:
8 Quando MCP vale a pena e quando não
Habilitar um servidor cobra atenção, manutenção e algum cuidado de segurança, e nem todo trabalho compensa essa conta.
| Faz sentido usar MCP quando… | É exagero quando… |
|---|---|
| Você precisa puxar 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ê quer que o Claude só explique código ou faça refactor local |
| A integração será reusada em vários projetos ou pela equipe | É uma consulta única que você faz uma vez no ano |
| Há um servidor oficial mantido pelo provedor do serviço | Você teria que escrever o servidor do zero e o ganho é marginal |
Para fluxos de análise dentro de um projeto local — ler CSVs, rodar R, gerar Quarto, fazer commits —, o Claude Code já entrega tudo nativamente, sem MCP. O protocolo entra em cena quando o trabalho cruza a fronteira do projeto e envolve outras pessoas, outros sistemas e outros dados.
9 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. Algumas atitudes que poupam dor de cabeça:
- Comece pelos servidores oficiais. Notion, GitHub, Linear e Asana têm servidores mantidos pelos próprios provedores, hospedados por eles, com OAuth nativo. Servidores de terceiros existem e funcionam, mas exigem que você confie no autor: leia o código antes de instalar.
- Use escopos mínimos no OAuth. Quando autorizar, prefira permissões só de leitura para experimentar. Você sobe para escrita quando precisar, e a volta nem sempre é simples em alguns serviços.
- Mantenha o
.mcp.jsonno repositório só com servidores oficiais. Servidores customizados, de equipe interna ou em teste ficam melhor em escopo local ou user, até você ter certeza de que valem para todo mundo. - Confirme a primeira chamada de cada ferramenta. A interface do Claude Code mostra exatamente o que será enviado para o servidor antes de executar, e vale ler ao menos nas primeiras invocações de uma ferramenta nova, para entender o padrão.
- Revogue acesso quando trocar de máquina ou sair de um time. O token continua válido até alguém apagar no painel do serviço.
