O que é MCP, e por que toda ferramenta de IA de repente fala essa língua?
Durante a maior parte da última década, conectar um modelo de IA às ferramentas da sua empresa significava uma integração sob medida para cada par. O Model Context Protocol, o padrão aberto que a Anthropic apresentou em novembro de 2024, substituiu isso por um único conector que encaixa em todo lugar — e OpenAI, Google e Microsoft o adotaram desde então. Veja como ele funciona de fato, e um checklist real antes de conectar um aos dados da sua equipe.
Abra o app de desktop do Claude e peça para ele conferir as pull requests abertas da sua equipe: ele simplesmente consegue. Não porque a Anthropic tenha embutido uma integração com o GitHub no Claude. Porque em algum lugar — a sua equipe de TI, um fornecedor, um desenvolvedor no GitHub — alguém escreveu um programa pequeno que fala um protocolo chamado MCP, e o Claude já sabe conversar com qualquer coisa que fale esse protocolo. O mesmo agora vale para o ChatGPT, o Gemini do Google e o Microsoft Copilot. Essa convergência, mais do que qualquer lançamento isolado de funcionalidade, é o motivo pelo qual o MCP se tornou aquilo para o qual quase todo fornecedor de IA passou o último ano construindo suporte.
O que o MCP realmente é
MCP significa Model Context Protocol. A Anthropic o desenhou e publicou a especificação em código aberto, junto com os primeiros SDKs, em 25 de novembro de 2024. O material de lançamento descreveu a ideia com uma analogia que ficou: pense no MCP como uma porta USB-C para aplicações de IA — um padrão de conector físico, em vez de um cabo diferente para cada acessório. No lançamento, a Anthropic citou os primeiros adotantes que já estavam colocando suporte a MCP nos próprios produtos, entre eles as empresas de software empresarial Block e Apollo e os fabricantes de ferramentas para desenvolvedores Zed, Replit, Codeium e Sourcegraph. O app de desktop do Claude saiu, no mesmo dia, com a capacidade de executar servidores MCP localmente na máquina de uma pessoa.
O problema que ele resolve: N ferramentas vezes M fontes de dados
O problema que o MCP resolve tem um nome que engenheiros usam com naturalidade: o problema de integração N por M. Digamos que uma empresa use cinco ferramentas de IA que precisam agir sobre os dados da companhia — Claude, ChatGPT, GitHub Copilot, Cursor e um bot de suporte interno — e que esses dados vivam em oito lugares: Slack, GitHub, um banco Postgres, Salesforce, Notion, Google Drive, Jira e uma API interna. Sem um protocolo compartilhado, ligar cada ferramenta a cada fonte de um jeito útil exige até quarenta integrações separadas — cinco vezes oito — cada uma com o próprio esquema de autenticação, o próprio tratamento de erros e o próprio custo de manutenção toda vez que uma dessas APIs muda de forma. Acrescente uma sexta ferramenta de IA e o número salta para quarenta e oito. Na prática, ninguém construiu as quarenta. Cada fornecedor de IA construiu o punhado que julgou valer o tempo de engenharia, e o resto ficou manual: copiar, colar, explicar de novo, repetir.
O MCP transforma a multiplicação em adição. Uma empresa que quer que o Claude leia do seu banco Postgres não constrói um conector Postgres específico para o Claude. Ela constrói — ou reutiliza um que outra pessoa já publicou — um servidor MCP que expõe o Postgres, e esse servidor funciona com Claude, ChatGPT, Gemini ou qualquer outro agente compatível com MCP, sem código adicional. A própria lista da Anthropic, no lançamento, citava servidores prontos para Google Drive, Slack, GitHub, Git, Postgres e uma ferramenta de automação de navegador chamada Puppeteer. O ponto nunca foi que a Anthropic construiria todos. É que qualquer um podia, e o catálogo de servidores disponíveis cresceu muito além do que uma única empresa conseguiria manter com a própria equipe.
Como o protocolo funciona de fato
Tirado o enquadramento, MCP é um protocolo cliente-servidor bem direto, de propósito sem glamour. Ele define três papéis. Um Host é o aplicativo que uma pessoa realmente abre — Claude Desktop, uma IDE como o Cursor, o app do ChatGPT. O Host incorpora um MCP Client, que abre uma conexão direta e com estado para um MCP Server — um programa pequeno que expõe um sistema específico: um banco de dados, uma ferramenta de chamados, um sistema de arquivos, uma API interna. Cliente e servidor trocam mensagens no formato JSON-RPC 2.0, um formato leve de chamada de procedimento remoto já comum na infraestrutura existente, por um de dois transportes: stdio, quando o servidor é um programa rodando localmente na mesma máquina, ou Streamable HTTP, quando é um serviço hospedado rodando em outro lugar.
O que um servidor pode expor se resume a três primitivas. Tools são funções que o modelo pode chamar para agir — create_task, run_query, send_message — e o modelo decide quando chamar uma com base na conversa. Resources são contexto somente leitura que o Host pode puxar e entregar ao modelo sem que ele precise pedir — o conteúdo de um arquivo, um esquema de banco, um chamado de suporte. Prompts são modelos reutilizáveis, disparados pela pessoa — um "resuma esta thread" ou "rascunhe uma atualização de status" pronto, que alguém invoca de forma explícita, em vez de algo que o modelo decide fazer sozinho. Um servidor bem construído deixa explícito qual dos três oferece para uma capacidade dada, porque essa distinção é exatamente o que determina se uma ferramenta de IA conectada pode olhar algo ou alterá-lo.
Quem mais adotou, e quando
Os primeiros meses do MCP foram um projeto só da Anthropic. Isso mudou rápido, e de um jeito genuinamente incomum em IA: concorrentes diretos convergiram para o protocolo de uma única empresa em vez de lançar o próprio. A OpenAI adicionou suporte a MCP ao seu Agents SDK em março de 2025, permitindo que desenvolvedores conectassem fluxos de agentes a qualquer servidor MCP em vez de construir integrações de ferramentas sob medida, específicas da OpenAI. No mês seguinte, o Google DeepMind confirmou que o Gemini e o próprio kit de desenvolvimento de agentes também suportariam MCP — um movimento que o Google pareou com o próprio protocolo complementar, Agent2Agent, voltado a deixar agentes independentes se coordenarem entre si, e não só com ferramentas. Em maio de 2025, a Microsoft tinha levado suporte nativo a MCP para o Windows 11 por meio do que chama de Windows AI Foundry, com o suporte também chegando ao GitHub Copilot e ao Copilot Studio.
Nenhuma dessas quatro empresas concorda em muita coisa quando o assunto é arquitetura de modelos, preço ou estratégia de plataforma. As quatro agora entregam produtos que falam o mesmo protocolo para conectar um agente a uma ferramenta. Isso é raro o bastante neste setor para ser a história de verdade — mais do que qualquer funcionalidade isolada que o MCP torna possível.
Por que isso é uma questão de confiança, não só de encanamento
Essa convergência é genuinamente útil, e é exatamente por isso que o MCP merece escrutínio em vez de confiança cega. Um protocolo que torna banal um agente se conectar aos sistemas da sua empresa é um protocolo que torna banal uma conexão mal construída ou mal configurada alcançar esses mesmos sistemas. O MCP em si não impede isso. A especificação define como um cliente e um servidor conversam — não diz nada sobre quem pode conceder uma conexão, o que essa conexão pode tocar, ou se alguém vai perceber se algo der errado. Essas escolhas ficam inteiramente com quem construiu ou configurou o servidor ou o cliente específico à sua frente. Alguns fornecedores constroem tudo isso com cuidado. Outros não constroem nada disso, e o protocolo não vai impedi-los.
MCP é um protocolo de fiação, não um sistema de controle de acesso. Ele padroniza como um agente pede a uma ferramenta que faça algo. Se esse pedido é delimitado, registrado e revogável é uma decisão que alguém tomou — ou não tomou — por cima dele.
Um checklist antes de conectar um
Antes de a sua equipe conectar um servidor MCP — seja um produto de fornecedor, uma ferramenta de código aberto que alguém encontrou no GitHub, ou algo construído internamente — seis perguntas separam uma conexão governada de uma porta aberta. Nenhuma exige ler a especificação. Elas só exigem que alguém pergunte antes de clicar em aprovar, e que leia de fato a resposta que a tela de conexão devolve.
| Pergunte isto | Como o bom se parece | Fique de olho |
|---|---|---|
| Quais escopos ou tools ele solicita? | Detalhado Uma lista nomeada e específica que você pode ler antes de aprovar — "criar tarefas, ler mensagens neste canal". | Amplo "Acesso total à conta", sem uma lista do que ele de fato pode fazer. |
| É somente leitura, ou pode escrever e agir? | Separado Acesso de leitura por padrão; qualquer ação que altere dados precisa da própria concessão visível. | Empacotado Acesso de escrita incluído automaticamente, sem jeito de saber qual capacidade faz o quê. |
| É por pessoa ou compartilhado com a equipe toda? | Por pessoa Cada pessoa entra com o próprio login; o agente só vê o que essa pessoa pode ver. | Compartilhado Uma chave de API ou conta de serviço usada pela equipe inteira, contornando permissões individuais. |
| Existe um registro de auditoria do que ele fez? | Registrado Cada chamada de ferramenta fica anotada — quem conectou, o que tocou e quando. | Sem registro Nenhum rastro além do que a própria ferramenta de IA escolhe contar. |
| Dá para revogar na hora? | Imediato Um interruptor, com efeito na hora, numa página de configurações que você controla. | Demorado Revogar exige um chamado de suporte, uma ligação ao fornecedor, ou não é possível. |
| Revogar isso quebra alguma outra coisa? | Isolado Limitado a essa única conexão; desligar afeta só ela. | Entrelaçado Compartilha uma credencial com outras ferramentas, então revogar uma quebra outras três em silêncio. |
Como uma conexão bem construída realmente se parece
A própria configuração MCP do FabricLoop é uma resposta concreta a esse checklist — não porque seja incomum, mas porque cada peça corresponde diretamente a uma das seis perguntas acima, e vale nomear a mecânica real em vez da versão de marketing. O FabricLoop ocupa os dois papéis ao mesmo tempo: é um servidor MCP ao qual ferramentas externas se conectam, para que Cursor, Claude ou ChatGPT possam criar uma tarefa, adicionar um comentário ou ler uma nota usando as permissões FabricLoop de uma pessoa específica — e é um cliente MCP que se conecta para fora, para que um canal possa trazer o app MCP de um fornecedor, como GitHub ou Linear, e mencioná-lo com @ como um colega de equipe.
Toda conexão, nos dois sentidos, começa com uma pessoa, não com um workspace. Conectar um cliente externo como o Cursor abre uma tela de consentimento OAuth em app.fabricloop.com/oauth/consent, onde essa pessoa escolhe um workspace e aprova os tools específicos que o cliente pede — o cliente só pode agir depois com os escopos concedidos naquela tela, sob as permissões dessa única pessoa, nunca com uma conta de serviço compartilhada. O sentido inverso funciona do mesmo jeito: um administrador pode habilitar o app MCP de um fornecedor para a equipe inteira, mas cada pessoa ainda conclui o próprio login antes que funcione para ela, e um administrador pode colocar esse app em modo somente leitura ou restringi-lo a uma lista de tools específicos, em vez de tudo o que o fornecedor expõe.
Cada cliente conectado aparece numa tela de configurações ao lado de um controle Revogar que o desconecta na hora — a página da própria pessoa, não um chamado de suporte. Nos planos Enterprise, essa atividade — inclusive concessões MCP e o que um agente conectado de fato fez — cai num registro de auditoria que uma equipe de segurança pode revisar quando quiser, em vez de capturas de tela tiradas de uma thread de chat depois do fato.
Nada disso é engenharia exótica. É um conjunto pequeno de decisões, de propósito sem glamour, repetidas com constância: delimitar, vincular a uma pessoa, registrar, tornar revogável sem dano colateral. É o mesmo argumento que este site faz de forma mais ampla sobre Legibility — acesso que se pode nomear, registrar e revogar ganha de acesso sobre o qual ninguém precisa pensar — e o MCP só entrega isso quando alguém constrói dessa forma. O protocolo torna o encanamento padrão. Não torna a governança automática.
A decisão que realmente importa
O MCP não vai embora, e se opor a ele neste ponto parece um pouco com se opor ao USB. Todo grande fornecedor de modelos agora o entrega, a lista de servidores disponíveis continua crescendo, e um agente que não alcança as suas ferramentas é, para a maior parte do trabalho real, um agente que não consegue fazer muita coisa. A decisão interessante não é deixar ou não uma ferramenta de IA se conectar aos seus sistemas — cada vez mais, alguma versão dessa decisão já está sendo tomada por você, uma integração de cada vez, enquanto ferramentas que a sua equipe já usa acrescentam suporte a MCP em silêncio, por baixo de uma funcionalidade em que você clicou sem ler as letras miúdas. A decisão que ainda é de fato sua é o que você confere antes de clicar em aprovar.
O MCP padronizou como um agente de IA pede a uma ferramenta que faça algo. Não fez nada para padronizar se esse pedido é seguro de conceder — essa parte continua sendo, e vai continuar sendo, uma decisão da pessoa que clica em "aprovar".