Toda semana aparece uma sigla nova em IA e a maioria não sobrevive seis meses. O MCP (Model Context Protocol) é uma das que vale entender — não porque está na moda, mas porque resolve um problema real e chato que quem constrói agentes de IA conhece de cor: conectar o modelo às ferramentas do mundo real dá trabalho, e todo mundo reinventa a roda.
Este é o guia direto. O que é, o que resolve, quando usar de verdade — e quando é só complexidade a mais.
O problema que o MCP resolve
Um agente de IA que só conversa é um chatbot melhorado. Um agente que age — consulta um pedido, gera um boleto, abre um chamado — é software de verdade. Já escrevi sobre isso no guia de function calling: a diferença entre papo e produto são as ferramentas que o modelo pode acionar.
O problema é que, historicamente, cada ferramenta era conectada de um jeito. Você escreve o código que descreve a ferramenta pro modelo, o código que executa, o código que valida — tudo sob medida, pra aquele agente, naquele projeto. Aí você começa outro projeto e faz tudo de novo. A integração com o mesmo CRM que você já fez três vezes? De novo. Multiplique por dezenas de ferramentas e vários agentes e você tem um pântano de integrações que ninguém reaproveita.
O MCP ataca exatamente isso: padronizar como um LLM descobre e usa ferramentas externas, pra que uma integração feita uma vez sirva pra qualquer agente compatível.
A analogia do USB-C
Antes do USB-C, cada aparelho tinha seu conector. Carregador de um celular não servia no outro. O USB-C não deixou os aparelhos mais poderosos — ele deixou o acoplamento padrão, e de repente um cabo serve pra tudo.
O MCP é isso pra agentes de IA. Antes: cada "cliente" de IA (um agente, um app, um assistente) conectava a cada "servidor" de ferramenta (seu CRM, seu banco de dados, sua API) com fiação própria. Depois: o cliente fala MCP, o servidor fala MCP, e eles se entendem sem código sob medida.
Na prática, o protocolo define duas pontas:
- Servidor MCP: expõe capacidades — ferramentas (ações que o modelo pode executar), recursos (dados que ele pode ler) e prompts (instruções reutilizáveis). Quem tem um sistema (um ERP, uma base de conhecimento) escreve um servidor MCP uma vez.
- Cliente MCP: é o lado do agente/aplicação. Ele descobre o que o servidor oferece e disponibiliza isso ao modelo, de forma padronizada.
O ganho é composição: conecte um cliente a vários servidores, ou vários clientes ao mesmo servidor, sem reescrever a cola toda vez.
MCP não substitui function calling — ele o organiza
Aqui mora a confusão mais comum. MCP e function calling não são concorrentes.
- Function calling é a habilidade do modelo de, no meio da conversa, dizer "quero chamar a ferramenta
buscar_pedidocom esse argumento". É o raciocínio do modelo escolhendo agir. - MCP é o padrão de como aquela ferramenta é descrita, descoberta e exposta. É a tomada; function calling é a decisão de plugar.
Você continua precisando de function calling. O MCP só faz a ferramenta que o modelo chama vir de um lugar padronizado, em vez de fiação sob medida. Toda a disciplina que eu prego sobre ferramentas continua valendo — e vale reforçar:
O modelo não executa nada. Ele decide o quê chamar; quem executa, valida e confirma é o seu código, do seu lado. O MCP padroniza o transporte, não a responsabilidade. Um servidor MCP que executa ação irreversível sem validação e confirmação é tão perigoso quanto uma function calling mal feita. O protocolo não te salva de arquitetura ruim.
Quando usar MCP (e quando não)
Sou chato com isso porque já vi projeto morrer de complexidade adotada cedo demais. MCP é ferramenta, não religião.
Vale a pena quando:
- Você tem muitas ferramentas e quer reaproveitá-las entre agentes/projetos sem reescrever a cola.
- Você quer plugar servidores prontos de terceiros (um servidor MCP que já fala com determinado sistema) em vez de integrar do zero.
- Você está montando uma plataforma onde ferramentas entram e saem, e um padrão evita o caos de N integrações ad-hoc.
- Você quer que o mesmo conjunto de ferramentas sirva a clientes diferentes (um assistente de desktop, um agente no WhatsApp, um app interno).
Provavelmente é overkill quando:
- Seu agente é pequeno e focado, com três ou quatro ferramentas que só ele usa. Integração direta com function calling é mais simples e você não paga o custo de infra do protocolo.
- Você tem uma integração só e nenhum plano de reaproveitar. Padronizar um caso único é cerimônia sem retorno.
- O gargalo do seu projeto não é integração — é definição de escopo, qualidade da conversa ou a decisão de negócio. MCP não resolve nenhum desses.
A pergunta que eu faço: quantas vezes eu vou reaproveitar esta ferramenta? Se a resposta é "uma", integração direta. Se é "muitas, em lugares diferentes", o padrão começa a pagar por si.
O que o MCP muda no dia a dia de quem constrói
Menos cola, mais reuso. Um servidor MCP bem feito pro seu ERP vira um ativo: o próximo agente que precisar falar com o ERP já tem a tomada pronta. Isso encurta o caminho entre a ideia e o produto no ar — que é, no fim, o que importa.
Mas há custo. Você adiciona uma camada (cliente + servidor, transporte, descoberta) que precisa ser operada, versionada e monitorada como qualquer infraestrutura. Em produção, isso significa as mesmas perguntas de sempre: o que acontece se o servidor MCP cai? Como você loga o que cada ferramenta fez? Como valida a ação antes de executar? O protocolo padroniza o encanamento; a resiliência continua sendo trabalho seu — igual ao que descrevi na arquitetura de agentes que aguentam produção.
O resumo honesto
MCP é um padrão útil que resolve um problema real: a bagunça das integrações sob medida entre LLMs e ferramentas. Ele é o USB-C dos agentes — padroniza o acoplamento, não a inteligência. Não substitui function calling; organiza de onde as ferramentas vêm. Brilha em escala e reuso; é peso morto num agente pequeno e único.
Como toda tecnologia nova, o erro não é ignorá-la nem abraçá-la cega — é adotar sem perguntar que problema meu isso resolve hoje. Se você tem muitas ferramentas pra reaproveitar, vale estudar. Se você ainda está brigando pra botar o primeiro agente no ar, resolve o primeiro agente. O padrão vai estar lá quando a escala chegar.
Construo agentes de IA que agem em produção — com ou sem MCP, sempre com a integração real e a validação que o mundo de verdade exige. Se você tem ferramentas e sistemas pra conectar a um agente, vamos conversar.