MCP: A Arquitetura de Plugins que Faltava para Integrar LLMs com o Mundo Real
Se você já tentou conectar um LLM a ferramentas externas, provavelmente esbarrou no mesmo problema: cada integração é um projeto separado. Quer que seu agente leia arquivos? Implementa uma função. Precisa buscar dados no GitHub? Outra função. Quer consultar um banco de dados? Mais código customizado. Quando outro projeto precisa das mesmas integrações, você começa do zero.
A Anthropic lançou em novembro de 2024 uma proposta para resolver isso: o Model Context Protocol (MCP). É um protocolo aberto que padroniza como LLMs se conectam a fontes de dados e ferramentas externas, criando uma arquitetura de plugins reutilizáveis em vez de integrações ad-hoc.
A proposta é simples mas ambiciosa: construir um ecossistema onde qualquer desenvolvedor pode criar um “servidor MCP” que exponha funcionalidades (ler arquivos, consultar APIs, executar comandos) e qualquer aplicação com LLM pode consumir esses servidores sem código customizado. A especificação está sólida, mas como todo protocolo novo, ainda estamos descobrindo seus limites na prática.
Por Que Precisamos de Mais Um Protocolo
A abordagem tradicional de tool calling em LLMs é funcional mas não escala bem. Você define funções manualmente no código da sua aplicação, descreve os parâmetros em JSON Schema, e o LLM escolhe quando chamá-las. O problema surge quando você precisa das mesmas ferramentas em múltiplos projetos ou quando quer adicionar novas capacidades sem modificar o código principal.
Frameworks como LangChain tentam resolver isso com abstrações, mas ainda amarram você ao ecossistema específico do framework. Se você constrói uma integração LangChain para Slack, ela não funciona em projetos que usam LlamaIndex ou implementações customizadas. Cada framework tem sua própria forma de definir ferramentas, gerenciar estado e lidar com erros.
MCP propõe algo diferente: um protocolo de comunicação agnóstico a frameworks. Servidores MCP são processos independentes que expõem capacidades através de uma interface padronizada. Qualquer aplicação que implemente o protocolo pode se conectar a qualquer servidor, independentemente de como foi construído.
Arquitetura: Cliente-Servidor com Isolamento por Design
A decisão arquitetural central do MCP é executar cada servidor em um processo isolado. Aplicações LLM atuam como clientes MCP e se conectam a múltiplos servidores simultaneamente, cada um rodando independentemente. Essa separação permite controle granular de permissões e reduz o risco de um servidor comprometer todo o sistema.
A comunicação acontece via JSON-RPC 2.0, um protocolo request-response simples e bem estabelecido. O MCP suporta dois transportes principais: stdio (entrada/saída padrão) para servidores locais e HTTP com Server-Sent Events para cenários remotos. O transporte stdio é particularmente elegante para uso local — o host inicia o processo do servidor, se comunica via stdin/stdout e tem controle total do ciclo de vida.
O protocolo define três primitivas fundamentais:
Resources são dados que o servidor disponibiliza para leitura. Pense em arquivos, entradas de banco de dados, conteúdo de APIs. Um servidor de filesystem expõe arquivos como resources. Um servidor GitHub expõe issues e pull requests. O LLM pode listar resources disponíveis e solicitar seu conteúdo quando necessário.
Tools são funções executáveis que performam ações: criar um arquivo, enviar um email, fazer uma requisição HTTP. O LLM decide quando invocar uma tool baseado na tarefa, passa os parâmetros necessários (validados via JSON Schema) e recebe o resultado. É tool calling padronizado através de processo isolado.
Prompts são templates reutilizáveis que encapsulam padrões de interação. Um servidor pode expor prompts pré-configurados com contexto específico, permitindo workflows consistentes entre diferentes hosts.
O lifecycle de conexão é bem definido: cliente envia initialize com suas capabilities, servidor responde com suas próprias capabilities, cliente confirma com initialized e a comunicação está estabelecida. Há suporte para notificações de progresso em operações longas e cancelamento explícito de requisições.
Como Funciona na Prática: Filesystem Server
O repositório oficial inclui implementações de referência que demonstram os padrões. O filesystem server, implementado em cerca de 300 linhas de Python, é um bom exemplo de como as primitivas se traduzem em código funcional.
Ele expõe operações de arquivo como tools: read_file, write_file, create_directory, list_directory, move_file. Cada tool tem um JSON Schema rigoroso definindo parâmetros obrigatórios e opcionais. write_file requer path e content, mas pode receber opcionalmente create_directories como booleano.
Quando você registra este servidor no Claude Desktop através do arquivo de configuração, ele se torna disponível automaticamente. Pergunte “qual o conteúdo do arquivo package.json?” e o Claude pode invocar a tool read_file com o path apropriado. Peça “crie um novo arquivo README.md com uma descrição do projeto” e ele usa write_file.
O servidor implementa validação de segurança própria. Ele pode restringir operações a diretórios específicos, bloquear acesso a paths sensíveis ou requerer confirmação do usuário para operações destrutivas. Essa lógica fica encapsulada no servidor, não espalhada pelo código que usa o LLM.
Outros servidores no repositório oficial seguem padrões similares. O servidor PostgreSQL expõe queries como tools, com validação de sintaxe SQL. O servidor Puppeteer permite automação de browser. O servidor Brave Search integra busca web. Cada um é independente e pode ser composto conforme necessário.
Isolamento vs. Performance: O Trade-off Fundamental
A arquitetura de processos isolados traz segurança e modularidade, mas tem custo. Cada chamada a um servidor MCP atravessa uma barreira de processo: serialização JSON, comunicação IPC, deserialização do outro lado. Para operações locais simples como ler um arquivo pequeno, esse overhead pode ser perceptível comparado a uma função nativa.
A documentação oficial não especifica métricas de latência ou throughput, e benchmarks públicos não estão disponíveis ainda. Discussões na comunidade técnica mencionam preocupações sobre o overhead de comunicação, mas sem dados quantitativos. É um trade-off clássico: você prioriza segurança e composabilidade sobre raw performance.
Para muitos casos de uso com LLMs, esse trade-off faz sentido. As chamadas ao próprio LLM têm latência de centenas de milissegundos ou mais. Adicionar 10-50ms de overhead de comunicação com servidores MCP provavelmente não é o gargalo. Mas para aplicações que precisam de milhares de tool calls por segundo com latência mínima, a arquitetura de processos separados pode ser limitante.
MCP foi lançado em novembro de 2024, então casos de uso em produção enterprise-scale ainda não estão documentados. A primeira versão estável focou especificamente em Claude Desktop, embora o protocolo seja projetado para ser agnóstico a LLMs. Padrões para escalar servidores MCP além de uso local (clustering, load balancing) ainda não estão definidos na especificação.
O Ecossistema Está Tomando Forma
A proposta de valor do MCP depende fundamentalmente do ecossistema que se forma ao redor dele. Um protocolo padronizado só é útil se há implementações suficientes para justificar a adoção.
Os sinais iniciais são positivos. O Google lançou o ADK-Go (Agent Development Kit em Go) baseado em MCP, demonstrando interesse além da Anthropic. O repositório oficial de servidores continua crescendo com contribuições da comunidade. Integrações com ferramentas populares como Slack, GitHub e PostgreSQL já existem como referência.
O modelo de desenvolvimento lembra a evolução de padrões web como OAuth ou OpenAPI: especificação aberta, implementações de referência, adoção gradual conforme o valor se prova na prática. A diferença é que MCP está chegando em um momento onde LLMs estão rapidamente se tornando commodity e a necessidade de integrações padronizadas é óbvia.
A verdadeira pergunta não é se precisamos de algo como MCP, mas se este protocolo específico vai emergir como o padrão de facto. Isso depende de fatores além da qualidade técnica: facilidade de implementação, suporte de ferramentas populares, momentum da comunidade e ausência de alternativas suficientemente melhores.
Você pode começar a experimentar com MCP hoje através do Claude Desktop e dos servidores de referência. A especificação completa está disponível em spec.modelcontextprotocol.io e os SDKs em Python e TypeScript facilitam criar seus próprios servidores. Para uso local em desenvolvimento, a configuração é direta: registre servidores no arquivo JSON de configuração e eles aparecem automaticamente no Claude.
O protocolo resolve um problema real de forma elegante. Se vai se tornar o padrão universal para integrações de LLMs é uma questão que só o tempo e a adoção da comunidade vão responder. A arquitetura é sólida o suficiente para justificar atenção séria de quem está construindo sistemas com agentes.