IA: MCP - Model Context Protocol | A Teoria (Parte 3)

Esse tipo de texto envelhece muito rápido. Gosto de escrever sobre assuntos que são atemporais. Mas sendo esse o objeto de estudo nas últimas semanas, escrever sobre ele é obrigação.

Esse artigo vai ser a parte teórica do Model Context Protocol (MCP). Estou escrevendo outro usando na prática o MCP.

Definição

O Model Context Protocol (MCP) é um protocolo. É importante deixar isso claro: não se trata de uma IA, um aplicativo, um modelo ou uma ferramenta.

O objetivo de qualquer protocolo é padronizar e permitir a comunicação entre dois ou mais sistemas.

Já escrevi sobre LLMs e Agentes. O MCP é o próximo passo. Com o surgimento de vários LLMs e Agentes, o MCP surgiu com a proposta de padronizar a comunicação nesse universo de IA e tentar colocar ordem na casa. Ele surge com o objetivo de integrar sistemas que não são necessariamente de IA, como bancos de dados, ferramentas de produtividade, automação, desenvolvimento, etc.

O objetivo do MCP vai além de apenas integrar LLMs e Agentes. A proposta é conectar qualquer sistema a outro que utilize o MCP, sendo que modelos de IA e agentes são apenas alguns exemplos desses sistemas.

O que precisa estar mais claro é o objetivo REAL. Modelos de IA são treinados e são fechados. Existe esse conceito de "AI está aprendendo enquanto você a usa", mas na prática não é bem assim. Talvez em um contexto bem delimitado, por exemplo, uma conversa/chat em um modelo, ele sim vai "aprender" com o que você está interagindo. Mas não sai daquele contexto.

Retomando o objetivo REAL do MCP, como os modelos são fechados, como eu "adiciono" informações a ele? A resposta simples seria: Pelo prompt. Dar um contexto a ele. Mas isso não funciona quando estamos falando de quantidades relevantes de dados. Ok, mas já resolvemos isso com RAGs, Agentes, etc. Porém, cada um fez "do seu jeito". MCP é a tentativa de padronizar isso.

Essa é a proposta. Vamos entender como ele se propõe a fazer isso.

Surgimento

Em novembro do ano passado (2024), a Anthropic publicou um artigo chamado Introducing the Model Context Protocol, juntamente com uma documentação.

No lançamento, o artigo não teve muito destaque, mas ganhou notoriedade principalmente quando a OpenAI passou a adotar o protocolo.

O Básico

O protocolo descreve uma forma de sistemas proverem contexto para as LLMs e como as LLMs podem se conectar a diferentes fontes de dados ("data sources") e ferramentas.

Primeiro, você precisa de um "Host", que é o sistema que utiliza IA e implementa o MCP Client. Por exemplo: VSCode, Cursor, Claude, etc.

Por outro lado, existe o MCP Server, que é o sistema responsável por fornecer contexto para o Host. Podemos ter um MCP Server para lidar com o banco de dados MySQL, por exemplo. Assim, temos três partes: MCP Client (Claude), MCP Server (MCP MySQL) e Data Sources (MySQL). Nossa comunicação será com o MCP Server, que por sua vez irá lidar com o MySQL e resolver a nossa requisição.

Por exemplo, se eu solicitar ao MCP Server: "Me traga os últimos registros da tabela de pagamento", o MCP Server irá se conectar ao banco de dados MySQL, fazer a consulta e retornar os dados para o MCP Client. Esses dados podem ser usados como contexto para um modelo, para refinar esses dados, ou simplesmente retornar os dados para o usuário. A imagem abaixo talvez ajude a ilustrar.

Exemplo de Arquitetura MCP

Usei o MySQL como exemplo, mas não há muitos limites para os cenários. Existem MCP Servers para lidar com APIs, até mesmo para Docker local, etc.

Possibilidades de conexões

O host pode implementar um client, que conta inclusive com um SDK contendo todas as especificações. Esse client, presente no host, se comunica com o MCP Server. Podemos realizar tanto chamadas locais, dentro do próprio computador, quanto chamadas externas, ou seja, remotas.

Assim, é possível acessar e modificar o sistema de arquivos local, mas também ler dados de serviços como o Google Drive ou acessar informações em uma pasta remota.

Cada implementação requer um tipo de integração diferente, dependendo do cenário.

Para deixar clara a diferença entre MCP Client e MCP Server: exemplos de aplicações que implementam MCP Clients são GitHub Copilot, Cursor, Cloud Desktop, Cloud Code, entre outras. Todas essas ferramentas possuem internamente um client para se comunicar com um MCP Server.

Já exemplos de MCP Servers incluem: servidores para Postgres, Google Drive, Git, GitHub, Slack, sistema de arquivos, Docker, Kubernetes, entre outros.

Exemplos de Servidores MCP Populares

O ecossistema MCP está crescendo rapidamente, com servidores para os mais diversos cenários. Abaixo estão alguns exemplos populares e amplamente utilizados, tanto de referência quanto de produção:

Filesystem: Operações seguras em arquivos locais, com controle de acesso configurável.
Git: Leitura, busca e manipulação de repositórios Git.
Google Drive: Acesso e busca de arquivos no Google Drive.
PostgreSQL: Acesso a bancos de dados PostgreSQL (leitura e inspeção de schema).
Slack: Gerenciamento de canais e mensagens no Slack.
Sentry: Consulta e análise de issues do Sentry.io.
Brave Search: Busca web e local usando a API do Brave.
Puppeteer: Automação de navegador e web scraping.
Memory: Sistema de memória persistente baseado em grafo de conhecimento.
Fetch: Busca e conversão de conteúdo web para uso eficiente por LLMs.

Além desses, há servidores oficiais mantidos por grandes empresas e uma enorme variedade de servidores comunitários para integrações com APIs, bancos de dados, automação, produtividade, cloud, entre outros.

Para uma lista sempre atualizada, consulte:

Esses repositórios trazem dezenas de opções, incluindo integrações com Notion, Jira, Supabase, Stripe, Discord, AWS, Docker, e muito mais.

Arquitetura de um MCP Server: Tools e Resources

Agora vamos entender um pouco mais sobre a arquitetura de um MCP Server. O mais comum é falar sobre as ferramentas, ou "Tools". Uma Tool é uma ferramenta que realiza uma ação e é controlada diretamente pelos modelos de IA. Ou seja, a LLM decide quando chamar a ferramenta, dependendo do que você está solicitando ao modelo. Todo servidor MCP possui auto discovery: ele recebe a solicitação e busca em seu glossário a ferramenta mais apropriada para executar a ação.

Uma "Tool" é considerada um recurso poderoso porque consegue realizar ações, como criar um arquivo, chamar uma API, derrubar um contêiner, criar um pod de Kubernetes ou executar qualquer outra tarefa. E essa execução é controlada pelo modelo de IA.

Além das ferramentas, o MCP Server também possui os "Resources", que funcionam como conjuntos de dados. Eles permitem que os clientes obtenham dados para serem usados como contexto por uma LLM, por exemplo.

Atualmente, é comum utilizar RAGs (Retrieval-Augmented Generation), onde todos os dados da empresa são vetorizados e, quando necessário, realiza-se uma busca nesse banco de dados utilizando vetores para trazer o conteúdo relevante e embutir no prompt. Esse tipo de tarefa é custosa e trabalhosa, mas com Resources não é mais necessário fazer isso manualmente.

O MCP oferece um "cardápio" de recursos, onde é possível acessar informações específicas, como preços de produtos ou imagens de balancetes, por meio de endpoints próprios. Assim, essas informações podem ser usadas como contexto em uma LLM.

Prompt Templates

Além de Tools e Resources, o MCP também suporta o conceito de Prompt Templates. Um Prompt Template é um modelo de prompt reutilizável, definido no servidor MCP, que pode ser utilizado por clientes para padronizar e facilitar a criação de prompts para diferentes tarefas. Esses templates funcionam como "receitas" de prompts, permitindo que aplicações ou usuários preencham apenas as variáveis necessárias, sem precisar construir o prompt do zero a cada vez.

Por exemplo, um Prompt Template pode ser criado para gerar resumos de documentos, análises de código, ou respostas a perguntas frequentes. O template define a estrutura e os parâmetros esperados, e o cliente apenas fornece os valores específicos para cada uso. Isso garante consistência, reduz erros e acelera o desenvolvimento de integrações com modelos de IA.

No contexto do MCP, os Prompt Templates são especialmente úteis para empresas que desejam padronizar a comunicação com modelos de IA, garantindo que todos os prompts sigam as melhores práticas e estejam alinhados com os objetivos do negócio. Além disso, facilita a manutenção e atualização dos prompts, já que basta alterar o template no servidor MCP para que todas as aplicações passem a usar a nova versão automaticamente.

Sampling

Outro conceito importante no MCP é o Sampling. Sampling, no contexto do protocolo, refere-se ao controle de como e quando o modelo de IA deve interagir com as ferramentas (Tools) disponíveis em um MCP Server. Em vez de simplesmente executar todas as ferramentas disponíveis ou seguir um fluxo fixo, o Sampling permite que o modelo escolha, de forma controlada, quais ações tomar e em que momento.

O Sampling pode ser configurado para definir, por exemplo, quantas vezes uma ferramenta pode ser chamada em uma mesma interação, ou limitar o número de tentativas para obter uma resposta satisfatória. Isso é fundamental para evitar loops infinitos, uso excessivo de recursos ou respostas redundantes, além de garantir maior previsibilidade e segurança na execução das ações.

Na prática, o Sampling funciona como um mecanismo de governança: ele estabelece limites e regras para o uso das ferramentas, ajudando a balancear eficiência, custo e segurança. Empresas podem ajustar as configurações de Sampling conforme suas necessidades, otimizando o comportamento dos modelos de IA em diferentes cenários.

Esse controle é especialmente útil em ambientes onde múltiplas ferramentas estão disponíveis e o modelo precisa decidir, de forma inteligente, qual sequência de ações seguir para atingir o objetivo desejado.

Diferença entre Tool e Resource

Essa diferença entre Tools e Resources pode gerar confusão. Em tese, uma Tool pode fazer uma chamada de API e obter, por exemplo, uma tabela de preços, e tudo funcionará normalmente. No entanto, a principal utilidade das Tools é executar ações, e não apenas ler dados.

Outro ponto relevante é que o modelo de IA decide quando chamar uma Tool. Já no caso dos Resources, quem determina quando eles serão chamados é a aplicação que utiliza a inteligência artificial, e não o modelo. Na prática, são dois caminhos diferentes: se sua aplicação tem um chatbot e o cliente solicita o preço de um produto, você pode pedir para uma Tool, mas, como já sabe o que precisa, pode acessar diretamente o Resource.

Resource não é necessariamente apenas uma chamada de API. Resources podem ser qualquer tipo de documento: Google Drive, arquivos no sistema de arquivos, ou quaisquer outros dados.

A grande diferença é que as Tools são acionadas pelo modelo de IA, enquanto os Resources são acessados diretamente pela aplicação. Tools executam ações, enquanto Resources fornecem fontes de dados, sendo acessados pelo client.

Formatos de comunicação

Há dois formatos principais de comunicação. O primeiro é o Stdio, que é a entrada e saída padrão do sistema. Esse formato funciona bem quando o servidor MCP está rodando localmente na máquina. As mensagens são enviadas e recebidas utilizando o padrão JSON RPC.

Por outro lado, muitas vezes é necessário trabalhar com MCP remoto, ou seja, um serviço externo de MCP. Nesse cenário, é preciso usar outra forma de comunicação, via HTTP, chamada SSE (Server Sent Events). O SSE mantém uma conexão persistente entre client e server, permitindo comunicação eficiente. Embora o SSE seja tecnicamente unidirecional (do servidor para o cliente), no contexto do MCP ele é usado em conjunto com outras técnicas para criar uma comunicação bidirecional eficaz.

É muito mais fácil criar uma aplicação local do que um serviço online, especialmente utilizando SSE. É necessário se preocupar com segurança, rate limiting, autenticação e autorização. Não que o Stdio não exija cuidados com segurança, mas o nível de complexidade é diferente.

Limitações do protocolo

Apesar de ser um avanço importante na padronização da comunicação entre modelos de IA, agentes e sistemas externos, o MCP ainda possui algumas limitações:

Curva de aprendizado: A implementação do protocolo pode ser complexa para quem está começando, especialmente devido à variedade de conceitos (Tools, Resources, Prompt Templates, Sampling, etc.).
Padronização em evolução: O protocolo ainda está em desenvolvimento ativo, o que pode gerar mudanças frequentes e falta de estabilidade em algumas implementações.
Integração com sistemas legados: Nem todos os sistemas ou APIs possuem servidores MCP prontos, exigindo desenvolvimento customizado.
Segurança e governança: Embora o protocolo permita controles, a responsabilidade por autenticação, autorização e sandboxing é do implementador do servidor MCP.
Performance: Em cenários de alta demanda, a comunicação via MCP pode adicionar latência, especialmente em integrações remotas (SSE).
Adoção: Apesar do crescimento, ainda não é um padrão universal e pode não ser suportado por todas as ferramentas ou plataformas de IA.

Comparação com alternativas

O MCP não é a única forma de integrar modelos de IA com ferramentas e dados externos. Algumas alternativas e abordagens populares incluem:

OpenAI Function Calling: Permite que modelos da OpenAI chamem funções definidas pelo usuário, mas não define um protocolo universal para integração entre diferentes sistemas e agentes.
LangChain Tools/Agents: O framework LangChain oferece uma abordagem modular para conectar LLMs a ferramentas, bancos de dados e fluxos de trabalho, mas cada integração segue padrões próprios e não necessariamente interoperáveis com MCP.
LlamaIndex: Focado em integração de dados e RAG, permite conectar LLMs a fontes de dados estruturadas, mas não define um protocolo universal para ferramentas e ações.
APIs customizadas: Muitas empresas criam APIs REST ou gRPC específicas para conectar seus sistemas a modelos de IA, o que pode ser mais simples em cenários fechados, mas dificulta a interoperabilidade e manutenção.

A principal vantagem do MCP é justamente a padronização: ao adotar um protocolo comum, diferentes clientes, servidores e ferramentas podem interoperar sem necessidade de adaptações específicas para cada caso. Isso facilita a escalabilidade, manutenção e evolução do ecossistema de IA. No entanto, para casos muito simples ou altamente customizados, alternativas como function calling direto ou APIs específicas podem ser mais rápidas de implementar.

Conclusão

O Model Context Protocol (MCP) representa um avanço significativo na padronização da comunicação entre modelos de IA e sistemas externos. Sua proposta de criar um protocolo universal resolve um problema real: a fragmentação e falta de interoperabilidade no ecossistema de IA.

As principais contribuições do MCP incluem a separação clara entre Tools (ações), Resources (dados) e Prompt Templates (modelos reutilizáveis), além de mecanismos de controle como Sampling. Essa arquitetura permite que desenvolvedores criem integrações mais robustas e padronizadas, facilitando a manutenção e evolução das aplicações.

O protocolo oferece flexibilidade tanto para implementações locais (Stdio) quanto remotas (SSE), permitindo diferentes cenários de uso. O ecossistema já conta com dezenas de servidores MCP para as principais plataformas e serviços, demonstrando sua viabilidade prática.

No entanto, é importante reconhecer suas limitações atuais: a curva de aprendizado, a evolução constante do protocolo e questões de performance em alguns cenários. Além disso, a adoção ainda não é universal, e alternativas como OpenAI Function Calling ou LangChain podem ser mais adequadas em casos específicos.

O MCP está posicionado para se tornar um padrão importante no desenvolvimento de aplicações de IA, especialmente em cenários empresariais onde a padronização, segurança e escalabilidade são fundamentais. Sua adoção por empresas como Anthropic e OpenAI indica uma direção promissora para o futuro da integração entre IA e sistemas corporativos.

Para desenvolvedores e empresas, vale a pena acompanhar a evolução do protocolo e considerar sua adoção em novos projetos, especialmente aqueles que requerem integração com múltiplas fontes de dados e ferramentas.