Guia para iniciantes: entenda visualmente a arquitetura do MCP

O Model Context Protocol (MCP) abriu inúmeras possibilidades para expandir os recursos dos grandes modelos de linguagem. Ao mesmo tempo, também gerou certa confusão. Por isso, preparei um guia para iniciantes que mostra, com diagramas e tudo, como é a arquitetura do MCP.

Se você é desenvolvedor, provavelmente já ouviu falar de como os MCP Servers estão impulsionando o desenvolvimento de software no modo agentivo em ferramentas como Cursor, Windsurf e até nos novos fluxos de trabalho agentivos do VS Code. Mas o alcance deles vai além do desenvolvimento de software: eles também viabilizam experiências fluidas e ricas com LLMs para usuários finais, pois ampliam os dados com que o modelo foi treinado e aproveitam sua capacidade de raciocínio para executar ações.

Entenda o MCP

LLMs são, essencialmente, bases de conhecimento compactadas com todos os dados usados em seu treinamento. De forma semelhante ao funcionamento do nosso cérebro, eles aprendem por meio de redes neurais, o que lhes dá a capacidade de raciocinar e fazer grandes inferências lógicas que lembram a inteligência. Por mais impressionantes que sejam, os grandes modelos de linguagem ainda estão limitados aos próprios dados.

Os MCPs são a ponte que conecta os LLMs a conhecimentos e ações que estão além do seu alcance. Alguns diriam que isso já existia desde que a OpenAI introduziu os recursos de function calling ou tool calling, há algum tempo. Mas os MCPs levaram o conceito adiante: criaram um padrão aberto de comunicação, com interfaces estruturadas e fundamentadas, e viabilizaram a implantação e a descoberta de ferramentas de forma distribuída e dinâmica. Mais adiante, vamos falar sobre MCP e function calling.

MCP Hosts, MCP Clients e MCP Servers

Agora que explicamos o propósito dos MCPs, podemos explorar seus componentes. O MCP envolve, essencialmente, três entidades:

• O MCP Host é o aplicativo com tecnologia de IA que se integra aos MCPs. Alguns exemplos são Claude Desktop, Cursor, Windsurf, VS Code e outros. Esses aplicativos se integram aos MCPs por meio da implementação de um MCP Client.

• O MCP Client: é a camada de implementação em si, geralmente hospedada em aplicativos de IA completos, frameworks agentivos e outros aplicativos desse tipo. É a interface que se comunica com os MCP Servers.

• O MCP Server: é o componente que oferece recursos do “mundo real”. O LLM não tem acesso aos seus arquivos locais, certo? Mas, se um MCP Server os disponibilizar, o LLM poderá listá-los, lê-los e manipulá-los. Os MCP Servers implementam esses recursos ampliados, conhecimentos e ações aos quais o LLM passa a ter acesso.

Observação: você provavelmente verá que os MCP Hosts são chamados apenas de MCP Clients, porque esse termo passou a ser usado também para designar o aplicativo com tecnologia de IA.

Um resumo sobre function calling e ferramentas

Os MCP Servers geralmente disponibilizam ferramentas para os MCP Clients. Alguns exemplos são “ler um arquivo” ou “listar todas as ramificações de um repositório git remoto”.

Como isso funciona? Eles dizem ao LLM: “Ei, estas são as ferramentas que tenho disponíveis para você; uma delas se chama read_file”. Então, o LLM pode acionar essa ferramenta pelo Model Context Protocol, que, por sua vez, a associa a uma implementação de função real no código do MCP Server:

function tool_read_file(filepath) {
   // implementation
}

Mas as ferramentas não são novidade. O tool calling, também chamado de function calling, foi introduzido pela OpenAI no fim de 2023. O function calling foi então implementado em cada aplicativo com tecnologia de IA e precisava ser orquestrado especificamente pelo aplicativo para o LLM. Mais importante ainda: nem todos os modelos eram compatíveis com function calling.

Mais adiante, vamos explicar como os MCPs oferecem uma solução mais completa para o function calling.

Tipos de transporte dos MCP Servers: STDIO vs. HTTP

À primeira vista, o nome MCP Server pode dar a impressão de que se trata de um servidor de rede. Mas os MCPs ganharam destaque por serem processos executados localmente que se comunicam usando o transporte de entrada e saída padrão.

O que é STDIO?

STDIO (entrada, saída e erro padrão) é um mecanismo fundamental, baseado em texto, para a comunicação entre processos do sistema. Ou seja, comandos ou programas, como executar git no prompt de comando.

Quando um programa é executado, o sistema operacional estabelece três canais padrão: stdin, para receber entradas (geralmente do teclado ou da saída de outro programa); stdout, para saídas normais (geralmente destinadas ao terminal ou a um arquivo); e stderr, para mensagens de erro e diagnóstico (também normalmente destinadas ao terminal, mas muitas vezes separadas).

Em resumo, o STDIO permite que programas interajam com o sistema operacional ou com outros programas. Por exemplo, você pode direcionar a saída de um comando (stdout) para servir de entrada (stdin) a outro comando. Da mesma forma, pode redirecionar o stdout ou o stderr de um programa para um arquivo, para registrar informações ou consultá-las depois. Muitas ferramentas de linha de comando dependem bastante do STDIO para processar dados em pipelines e permitir interações básicas.

Em sistemas com arquitetura cliente-servidor, como os MCP Servers, o STDIO pode ser uma solução simples: o MCP Server é um processo que recebe solicitações via stdin e as envia de volta ao MCP Client como respostas em texto via stdout.

MCP Servers locais com STDIO

Os MCP Servers que usavam STDIO para se comunicar dependiam de um processo em execução e, por isso, na maioria dos casos, eram executados e instalados localmente.

Por isso, muitos aplicativos com tecnologia de IA (também chamados de MCP Hosts) pediam aos usuários que fornecessem definições de MCP Servers voltadas à execução de processos. Veja um exemplo simples de definição de MCP Server do mcp.json do Cursor:

// This example demonstrated an MCP server using the stdio format
// Cursor automatically runs this process for you
// This uses a Node.js server, ran with `npx`
{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "mcp-server"],
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

Como escalar MCP Servers na nuvem

Por fim, os MCP Servers podem cumprir plenamente seu potencial agora que o transporte HTTP está se popularizando em aplicativos de IA como Cursor e Claude Desktop, com o apoio de infraestrutura em nuvem para hospedar MCP Servers, como Vercel e Cloudflare.

Originalmente, os MCP Servers introduziram um transporte HTTP baseado em rede, usando um mecanismo chamado SSE (Server-Sent Events) para sincronizar e orquestrar mensagens entre o LLM e o MCP Server. Porém, assim como os WebSockets, o SSE exige servidores de longa duração, que não são tão acessíveis em plataformas modernas de implantação, como Vercel Functions ou AWS Lambdas. Assim, surgiu uma nova especificação, chamada Streamable HTTP, que permite usar HTTP sem servidor nos MCP Servers.

Os MCP Servers baseados em HTTP são fáceis de configurar, pois exigem apenas o endereço de um host remoto, sem especificações complexas de argumentos de linha de comando. Também ficou mais fácil compartilhar e acessar MCP Servers, já que eles não exigem mais um ambiente de desenvolvimento específico para instalação e execução local.

Por exemplo, o Cursor espera que MCP Servers remotos via HTTP sejam definidos de forma simples, como neste exemplo:  

// This example demonstrated an MCP server using the SSE format
// The user should manually setup and run the server
// This could be networked, to allow others to access it too
{
  "mcpServers": {
    "server-name": {
      "url": "http://example.com/sse",
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

A arquitetura do MCP: tudo integrado

Agora que já explicamos os componentes dos MCPs — como MCP Clients, MCP Servers, os tipos de transporte usados para a comunicação e exemplos práticos de cada um —, podemos entender melhor os modelos de implantação e a arquitetura geral dos MCPs.

A arquitetura do MCP permite implantações locais e remotas, viabilizando diversas estratégias de configuração e implantação. Por exemplo, você pode executar aplicativos de IA totalmente compatíveis com MCP de forma local. Veja um exemplo real: você instala localmente um aplicativo de IA, como o aplicativo de produtividade Raycast ou a IDE Cursor. Depois, conecta o Raycast ou o Cursor a um LLM em execução local por meio do Ollama. Os aplicativos Raycast ou Cursor executam um MCP Client local, que você configura para usar um MCP Server também local, como um MCP Server do SQLite, para consultar registros em bancos de dados baseados em arquivos.

Este é um exemplo de aplicativo com tecnologia de IA que funciona totalmente em um laptop, sem precisar de acesso à nuvem ou à rede.

Outra opção é combinar diferentes abordagens. Você pode implantar o MCP Server na infraestrutura de nuvem e disponibilizá-lo por meio do transporte HTTP. O MCP Client e o MCP Server se comunicam pelo Model Context Protocol, conforme a especificação, o que permite desacoplá-los completamente.

Além disso, embora a grande maioria dos aplicativos com tecnologia de IA tenha hospedado a implementação do MCP Client no próprio aplicativo de IA, isso não é obrigatório: o MCP Client também pode ser desacoplado do aplicativo de IA.

MCP vs. function calling: por que MCPs não são wrappers de APIs

Muita gente considera os MCPs “apenas mais um wrapper de API REST”. Essa visão é limitada e reduz a importância do MCP. Vamos entender por que os MCPs são mais complexos e adequados para aplicativos de IA.

Antes de nos aprofundarmos na confusão entre MCP e API REST, alguns desenvolvedores querem entender melhor como e por que os MCPs diferem do function calling original, disponibilizado pela OpenAI e seus SDKs em 2023.

MCP vs. function calling

Com o function calling, o aplicativo com tecnologia de IA precisava implementar cada ferramenta. Imagine que um aplicativo de IA como o Cursor precisasse implementar uma ferramenta git para “listar branches remotas”. Um aplicativo, como o Cursor, poderia implementá-la executando o comando git ls-remote, enquanto outro, como o Windsurf, talvez optasse por usar a API do GitHub. Cada abordagem resultaria em uma experiência de desenvolvimento e um tratamento de erros completamente diferentes, entre outras diferenças.

Essa falta de organização e padronização do function calling gerou duplicação desnecessária de código e lógica entre diferentes aplicativos com tecnologia de IA.

Em resumo, os MCPs oferecem as seguintes vantagens em relação ao function calling tradicional:

• Nas SDKs de function calling, as ferramentas eram vinculadas diretamente à integração com o LLM. Isso significava que:

• Não havia escalabilidade pronta para uso. Com os MCPs, você pode implantar o MCP Server e escalá-lo independentemente dos aplicativos de IA.

• Não havia uma separação clara de responsabilidades entre a implementação de uma ferramenta no aplicativo de IA e a lógica restante do aplicativo. Tudo fazia parte do mesmo componente. Tecnicamente, você poderia criar wrappers e interfaces entre eles e expô-los por meio de JSON-RPC, mas isso seria basicamente recriar os MCPs. É exatamente isso — e muito mais — que os MCPs oferecem.

• Não havia uma forma fácil de permitir que usuários da integração com o LLM ampliassem as ferramentas. Como a implementação do function calling fazia parte da integração com o LLM, ela ficava vinculada a essa integração. Permitir a extensão por ferramentas de terceiros seria reinventar os MCPs.

A vinculação rígida do function calling tradicional, criado inicialmente para definir ferramentas, também traz riscos de segurança. Operações potencialmente perigosas e sensíveis que as ferramentas precisam executar fazem parte do aplicativo de IA que as disponibiliza. Uma convenção de código insegura ou uma prática de segurança falha no nível da ferramenta poderia comprometer todo o aplicativo de IA.

Além da padronização das especificações que buscam oferecer, os MCPs proporcionam um tipo de IoC (inversão de controle), desacoplando o function calling e os recursos ampliados em serviços separados.

Os MCPs são apenas wrappers de APIs REST?

Reduzir os MCPs a APIs REST tradicionais é ignorar as complexidades do desenvolvimento de aplicativos de IA. Muitas características dos MCPs são semelhantes às das APIs REST: eles se comunicam por HTTP, usam JSON-RPC como formato subjacente do protocolo e adotam um modelo cliente-servidor. De fato, assim como os aplicativos web tradicionais, eles atendem a navegadores no lado do cliente e a outros clientes que consomem APIs.

No entanto, os MCPs costumam ser usados em um nível de granularidade diferente das APIs REST tradicionais e exigem recursos nativos de IA que as APIs REST não oferecem:

1. Os MCPs viabilizam casos de uso, não operações: Em outras palavras, pense nos MCPs como facilitadores de casos de uso voltados à solução de problemas. Os endpoints de APIs REST geralmente representam entidades e seu universo de forma granular. Os MCPs acabam criando uma matriz TxE (ferramentas × endpoints), na qual uma única implementação de ferramenta exposta pode corresponder a vários endpoints de APIs REST. Por exemplo, um MCP Server que disponibiliza a ferramenta “get_open_issues” para um repositório Git provavelmente precisaria consultar vários endpoints de APIs REST: 1) listar todos os issues abertos; 2) para cada ID de referência de issue aberto, obter todos os dados e metadados correspondentes. Os MCP Servers costumam ser menos granulares que uma API RESTful.

2. Os MCPs acionam ações além do ambiente web: É fácil pensar que tudo está conectado à web, mas muitas demonstrações incríveis de MCP envolvem interações que não usam a web nem APIs REST. Por exemplo, a demonstração viral do Blender MCP, que permitiu que o aplicativo de IA Claude criasse cenas 3D completas, foi baseada na API Python do Blender. Usar uma API nativa da linguagem para atender ao caso de uso do Blender libera a capacidade de raciocínio de programação do LLM e permite alcançar resultados melhores.

3. Os MCPs aproveitam os LLMs de forma nativa; as APIs REST, não: A especificação do MCP define um recurso chamado sampling, que permite ao MCP Server consultar o LLM para realizar uma operação específica. Veja um exemplo prático possível com MCPs, mas não com as APIs existentes, usando o exemplo anterior do Git: “listar os issues abertos com maior impacto na segurança”. Como uma API REST atenderia ao requisito de “maior impacto na segurança”? Se não houver um filtro ou uma tag relacionada a segurança nos issues, não há como buscar as informações relevantes. Com MCPs, porém, uma implementação de ferramenta pode obter a lista de issues abertos e enviar uma solicitação de sampling ao LLM com um prompt como “da lista a seguir de issues abertos, retorne em formato JSON uma lista ordenada dos que têm maior impacto na segurança”. Então, o LLM pode fazer o que faz de melhor e apresentar um resultado com análise aprofundada. O MCP usou um LLM como parte da resolução, algo que não está disponível de forma nativa em uma implementação de API REST existente. O sampling e a comunicação bidirecional com LLMs vão além da análise de similaridade ou sentimento: também aproveitam os pontos fortes multimodais dos LLMs e permitem aprimoramentos iterativos.

Questões de segurança relacionadas aos MCPs

Os MCPs também trazem preocupações de segurança. Como os MCP Servers são amplamente disseminados, surgem riscos à segurança da cadeia de suprimentos, como:

1. MCP Servers maliciosos - Como garantir que um MCP Server é confiável? O que acontece se ele executar ações às escondidas e exfiltrar informações confidenciais do seu ambiente local ou implantado? O MCP Server poderia conter uma backdoor? Como validar e se proteger contra esses riscos de segurança?

2. MCP Servers vulneráveis - Os MCP Servers podem funcionar como esperado, mas isso não significa que estejam livres de vulnerabilidades de segurança e falhas de codificação segura. Uma prática de codificação insegura em um MCP Server pode ser explorada por quem o utiliza e resultar em um comprometimento de segurança ou violação de dados.

Essas são apenas algumas das preocupações de segurança relacionadas aos MCPs. Os riscos de segurança envolvendo MCP e IA também incluem vulnerabilidades de segurança práticas na programação por vibe coding e como um LLM pode ser usado como arma por meio de injeção de prompt, além dos riscos de segurança da programação com ChatGPT.

Todas essas preocupações com a segurança da IA, entre outras, reforçam a necessidade de diretrizes de segurança para IA e proteção do código gerado por IA, riscos que a Snyk ajuda a mitigar.