O que é o MCP, e porque é que todas as ferramentas de IA falam de repente esta língua?
Durante a maior parte da última década, ligar um modelo de IA às ferramentas da empresa significava uma integração à medida para cada par. O Model Context Protocol, o padrão aberto que a Anthropic apresentou em novembro de 2024, substituiu isso por uma ficha que encaixa em todo o lado — e a OpenAI, a Google e a Microsoft adotaram-no desde então. Eis como funciona de facto, e uma lista de verificação real antes de ligar um aos dados da equipa.
Abra a aplicação de secretária do Claude e peça-lhe que verifique os pull requests em aberto da equipa, e ele consegue fazê-lo. Não porque a Anthropic tenha construído uma integração com o GitHub dentro do Claude. Porque algures — a equipa de TI, um fornecedor, um programador no GitHub — alguém escreveu um programa pequeno que fala um protocolo chamado MCP, e o Claude já sabe falar com tudo o que o fala. O mesmo vale agora para o ChatGPT, o Gemini da Google e o Microsoft Copilot. Essa convergência, mais do que qualquer lançamento isolado de funcionalidade, é a razão pela qual o MCP se tornou naquilo para o qual quase todos os fornecedores de IA passaram o último ano a construir suporte.
O que o MCP é, de facto
MCP significa Model Context Protocol. A Anthropic desenhou-o e publicou a especificação em código aberto, juntamente com os primeiros SDK, a 25 de novembro de 2024. Os próprios materiais de lançamento descreveram 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 nomeou os primeiros a adotar o protocolo e a construir já suporte MCP nos seus próprios produtos, incluindo as empresas de software empresarial Block e Apollo, e os fabricantes de ferramentas para programadores Zed, Replit, Codeium e Sourcegraph. A aplicação de secretária do Claude saiu, no mesmo dia, com a capacidade de executar servidores MCP localmente na máquina de uma pessoa.
O problema que resolve: N ferramentas vezes M fontes de dados
O problema que o MCP resolve tem um nome que os engenheiros usam com naturalidade: o problema de integração N por M. Imagine que uma empresa usa cinco ferramentas de IA que precisam de agir sobre dados da empresa — Claude, ChatGPT, GitHub Copilot, Cursor e um bot interno de suporte — e que esses dados vivem em oito sítios: Slack, GitHub, uma base de dados Postgres, Salesforce, Notion, Google Drive, Jira e uma API interna. Sem um protocolo partilhado, ligar cada ferramenta a cada fonte de forma útil exige até quarenta integrações separadas — cinco vezes oito — cada uma com o seu esquema de autenticação, o seu tratamento de erros e o seu imposto de manutenção sempre que uma dessas API 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 considerou valer o tempo de engenharia, e tudo o resto ficou manual: copiar, colar, voltar a explicar, repetir.
O MCP transforma a multiplicação em adição. Uma empresa que queira que o Claude leia a sua base de dados Postgres não constrói um conector Postgres específico do Claude. Constrói — ou reutiliza um que alguém já tenha publicado — um servidor MCP que expõe o Postgres, e esse servidor funciona com o Claude, o ChatGPT, o Gemini ou qualquer outro agente compatível com MCP, sem mais código. A própria lista da Anthropic, no lançamento, nomeava servidores pré-construídos para Google Drive, Slack, GitHub, Git, Postgres e uma ferramenta de automação de browser chamada Puppeteer. O ponto nunca foi que a Anthropic os construísse todos. É que qualquer pessoa podia, e o catálogo de servidores disponíveis cresceu muito para além do que uma única empresa conseguiria dotar de pessoal.
Como o protocolo funciona, de facto
Retirada a embalagem, o MCP é um protocolo cliente-servidor bastante simples, deliberadamente pouco glamoroso. Define três papéis. Um Host é a aplicação que uma pessoa abre de facto — Claude Desktop, um IDE como o Cursor, a aplicação ChatGPT. O Host incorpora um MCP Client, que abre uma ligação direta e com estado a um MCP Server — um programa pequeno que expõe um sistema específico: uma base de dados, uma ferramenta de tickets, um sistema de ficheiros, 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, sobre um de dois transportes: stdio, quando o servidor é um programa a correr localmente na mesma máquina, ou Streamable HTTP, quando é um serviço alojado a correr noutro sítio.
O que um servidor pode expor resume-se 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 só de leitura que o Host pode puxar e entregar ao modelo sem que este tenha de pedir — o conteúdo de um ficheiro, um esquema de base de dados, um ticket de suporte. Prompts são modelos reutilizáveis, acionados pela pessoa — um "resume esta conversa" ou "redige uma atualização de estado" pré-feito, que alguém invoca explicitamente, em vez de algo que o modelo decide fazer por conta própria. Um servidor bem construído é explícito sobre qual dos três oferece para uma dada capacidade, porque essa distinção é exatamente o que determina se uma ferramenta de IA ligada pode olhar para alguma coisa ou alterá-la.
Quem mais o adotou, e quando
Os primeiros meses do MCP foram um projeto só da Anthropic. Isso mudou depressa, e de uma forma genuinamente invulgar em IA: concorrentes diretos convergiram no protocolo de uma única empresa, em vez de lançarem o seu. A OpenAI acrescentou suporte MCP ao seu Agents SDK em março de 2025, permitindo aos programadores ligar fluxos de agentes a qualquer servidor MCP, em vez de construírem integrações de ferramentas à medida e específicas da OpenAI. No mês seguinte, a Google DeepMind confirmou que o Gemini e o seu próprio kit de desenvolvimento de agentes também suportariam MCP — um passo que a Google emparelhou com o seu protocolo complementar, Agent2Agent, pensado para deixar agentes independentes coordenarem-se entre si, e não apenas com ferramentas. Em maio de 2025, a Microsoft tinha trazido suporte MCP nativo ao Windows 11 através daquilo a que chama Windows AI Foundry, com suporte também a chegar ao GitHub Copilot e ao Copilot Studio.
Nenhuma destas quatro empresas está de acordo em grande coisa no que toca a arquitetura de modelos, preços ou estratégia de plataforma. As quatro enviam agora produtos que falam o mesmo protocolo para ligar um agente a uma ferramenta. Isso é suficientemente raro nesta indústria para ser a história a sério — mais do que qualquer funcionalidade individual que o MCP permita.
Porque é que isto é uma questão de confiança, não só de canalização
Essa convergência é genuinamente útil, e é também exatamente a razão pela qual o MCP merece escrutínio em vez de confiança cega. Um protocolo que torna trivial um agente ligar-se aos sistemas da empresa é um protocolo que torna trivial uma ligação mal construída ou mal configurada chegar a esses mesmos sistemas. O MCP em si não impede isso. A especificação define como um cliente e um servidor falam um com o outro — não diz nada sobre quem pode conceder uma ligação, o que essa ligação pode tocar, ou se alguém vai reparar se alguma coisa correr mal. Essas escolhas ficam inteiramente com quem construiu ou configurou o servidor ou o cliente concreto que tem à frente. Alguns fornecedores constroem tudo isso com cuidado. Alguns não constroem nada disso, e o protocolo não os vai impedir.
O MCP é um protocolo de fio, não um sistema de controlo de acesso. Padroniza a forma como um agente pede a uma ferramenta que faça alguma coisa. Se esse pedido tem âmbito, fica registado e pode ser revogado é uma decisão que alguém tomou — ou não — por cima dele.
Uma lista de verificação antes de ligar um
Antes de a equipa ligar um servidor MCP — seja um produto de um fornecedor, uma ferramenta de código aberto que alguém encontrou no GitHub, ou algo construído internamente — seis perguntas separam uma ligação governada de uma porta aberta. Nenhuma exige ler a especificação. Exigem apenas que alguém pergunte antes de clicar em aprovar, e que leia de facto a resposta que o ecrã de ligação devolve.
| Pergunte isto | Como é que o bom se parece | Fique atento a |
|---|---|---|
| Que âmbitos ou ferramentas pede? | Discriminado Uma lista nomeada e específica que se pode ler antes de aprovar — "criar tarefas, ler mensagens neste canal." | Genérico "Acesso total à conta", sem lista discriminada do que pode de facto fazer. |
| É só de leitura, ou pode escrever e agir? | Separado Acesso de leitura por defeito; qualquer ação que altere dados precisa da sua própria concessão visível. | Agrupado Acesso de escrita incluído automaticamente, sem forma de perceber que capacidade faz o quê. |
| É por pessoa ou partilhado por toda a equipa? | Por pessoa Cada pessoa inicia sessão com o seu próprio acesso; o agente só vê o que essa pessoa pode ver. | Partilhado Uma chave de API ou conta de serviço usada por toda a equipa, a contornar permissões individuais. |
| Existe um registo de auditoria do que fez? | Registado Cada chamada de ferramenta fica registada — quem a ligou, o que tocou e quando. | Sem registo Nenhum registo para além daquilo que a própria ferramenta de IA escolhe contar que aconteceu. |
| Pode ser revogado de imediato? | Imediato Um interruptor, com efeito na hora, numa página de definições que controla. | Demorado Revogar exige um ticket de suporte, uma chamada ao fornecedor, ou não é possível de todo. |
| Revogá-lo parte mais alguma coisa? | Isolado Limitado a essa ligação; desligá-la afeta só essa. | Entrelaçado Partilha uma credencial com outras ferramentas, por isso revogar uma parte em silêncio outras três. |
Como é que uma ligação bem construída se parece, de facto
A própria configuração MCP da FabricLoop é uma resposta concreta a essa lista — não porque seja invulgar, mas porque cada peça corresponde diretamente a uma das seis perguntas acima, e vale a pena nomear a mecânica real em vez da versão de marketing. A FabricLoop corre nos dois papéis ao mesmo tempo: é um servidor MCP ao qual ferramentas exteriores se ligam, para que o Cursor, o Claude ou o ChatGPT possam criar uma tarefa, acrescentar um comentário ou ler uma nota com as permissões FabricLoop da própria pessoa — e é um cliente MCP que se liga para fora, para que um canal possa puxar a aplicação MCP de um fornecedor, como o GitHub ou o Linear, e mencioná-la com @ como um colega de equipa.
Cada ligação, em qualquer direção, começa numa pessoa, não num espaço de trabalho. Ligar um cliente externo como o Cursor abre um ecrã de consentimento OAuth em app.fabricloop.com/oauth/consent, onde essa pessoa escolhe um espaço de trabalho e aprova as ferramentas específicas que o cliente pede — o cliente só pode então agir com os âmbitos concedidos nesse ecrã, sob as permissões dessa única pessoa, nunca de uma conta de serviço partilhada. A direção inversa funciona da mesma forma: um administrador pode ativar a aplicação MCP de um fornecedor para toda a equipa, mas cada pessoa continua a ter de concluir o seu próprio início de sessão antes de funcionar para ela, e um administrador pode pôr essa aplicação em modo só de leitura ou restringi-la a uma lista de permissão de ferramentas específicas, em vez de tudo o que o fornecedor expõe.
Cada cliente ligado aparece num ecrã de definições ao lado de um controlo Revogar que o desliga de imediato — na página da própria pessoa, não num ticket de suporte. Nos planos Enterprise, essa atividade — incluindo concessões MCP e o que um agente ligado fez de facto — cai num registo de auditoria que uma equipa de segurança pode rever quando quiser, em vez de capturas de ecrã tiradas de uma conversa depois do facto.
Nada disto é engenharia exótica. É um conjunto pequeno e deliberadamente pouco glamoroso de decisões, repetidas com consistência: limitar o âmbito, prender a uma pessoa, registar, tornar revogável sem danos colaterais. É o mesmo argumento que este site faz sobre a Legibilidade em termos mais amplos — um acesso que se pode nomear, registar e revogar ganha a um acesso sobre o qual ninguém tem de pensar — e o MCP só entrega isso quando alguém o constrói assim. O protocolo torna a canalização padrão. Não torna a governação automática.
A decisão que importa de facto
O MCP não vai desaparecer, e opor-se a ele neste ponto é um pouco como opor-se ao USB. Todos os grandes fornecedores de modelos já o enviam, a lista de servidores disponíveis continua a crescer, e um agente que não consegue chegar às ferramentas é, para a maior parte do trabalho real, um agente que não consegue fazer grande coisa. A decisão interessante não é se se deixa uma ferramenta de IA ligar-se aos sistemas — cada vez mais, alguma versão dessa decisão já está a ser tomada por si, uma integração de cada vez, à medida que ferramentas que a equipa já usa acrescentam em silêncio suporte MCP por baixo de uma funcionalidade em que se clicou sem ler as letras pequenas. A decisão que ainda é de facto sua é o que verifica antes de clicar em aprovar.
O MCP padronizou a forma como um agente de IA pede a uma ferramenta que faça alguma coisa. Não fez nada para padronizar se esse pedido é seguro de conceder — essa parte continua a ser, e continuará a ser, uma decisão da pessoa que clica em "aprovar".