Arquitetura MCP: análise técnica completa com diagramas

A arquitetura MCP é o conjunto fundamental de componentes e regras de comunicação que tornam o MCP (Model Context Protocol) possível. O MCP é um padrão de código aberto, e a arquitetura MCP é a infraestrutura subjacente sobre a qual ele funciona.

Toda arquitetura MCP contém três componentes principais e é construída em torno deles: um host, um cliente e um servidor. A estrutura de comunicação do MCP costuma ser descrita como composta por uma camada de dados e uma camada de transporte. A camada de dados é o conjunto de regras que define como as mensagens são formatadas (as solicitações MCP são enviadas em JSON-RPC 2.0). A camada de transporte leva essas mensagens, usando HTTP com streaming para conexões externas.

A arquitetura MCP é uma estrutura de servidor que implementa o Model Context Protocol, um padrão aberto para conectar modelos de IA a ferramentas, a recursos como bancos de dados e a prompts que ampliam o contexto de entrada. Esses elementos são chamados coletivamente de “primitivas”. Em última análise, a arquitetura MCP permite que os LLMs descubram quais ferramentas estão disponíveis e executem fluxos de trabalho, tudo sem exigir atualizações regulares no lado do cliente.

Diagrama da arquitetura MCP: um aplicativo de IA troca solicitações com um servidor MCP, que fornece ferramentas, recursos e prompts.

Desde que foi lançada pela Anthropic, a arquitetura MCP passou a ser amplamente usada em fluxos de trabalho de IA. Isso se deve, em grande parte, ao fato de ela substituir sistemas que exigem mais manutenção, como os construídos em torno de várias conexões de API, sem sacrificar o desempenho. Como todas as funcionalidades disponíveis ficam por trás do servidor MCP, apenas uma conexão é necessária, e atualizações e adições ficam imediatamente disponíveis para o aplicativo cliente.

O MCP oferece aos LLMs um meio de descobrir e chamar as ferramentas, os prompts e os recursos disponíveis para eles, seja no sistema local do aplicativo host, seja por meio de um provedor externo.

No caso das ferramentas, que dão acesso a funcionalidades externas, a descoberta envolve o host fazer uma chamada tools/list ao servidor MCP para descobrir quais ferramentas estão disponíveis. O LLM (ou, em alguns casos, o host) pode então ler as descrições das ferramentas disponíveis e solicitá-las conforme necessário. Prompts e recursos usam um processo semelhante.

Diagrama dos componentes da arquitetura MCP: um host que contém um LLM, um orquestrador e um cliente se conecta a um servidor MCP em duas etapas, primeiro a descoberta e depois as solicitações, e o servidor MCP expõe ferramentas, recursos e prompts.

Isso contrasta com a arquitetura personalizada baseada em APIs, que tem sido a norma no desenvolvimento de software, na qual funcionalidades externas ao aplicativo precisavam ser chamadas por meio de conexões dedicadas com solicitações formatadas com precisão.

O aplicativo host é a plataforma central de orquestração e se conecta a um LLM. Ferramentas conhecidas, como o Perplexity e o Claude Desktop, podem atuar como hosts em um sistema MCP.

Em um fluxo de trabalho simples, o usuário faz uma pergunta pela interface de chat. Em seguida, o componente orquestrador do host adiciona contexto à pergunta, informando ao LLM quais primitivas MCP estão disponíveis, junto com uma descrição de suas capacidades.

O cliente é um componente de software do aplicativo de IA. O MCP fornece uma interface padrão para que o cliente se comunique com servidores MCP internos e externos com base nas instruções do host ou do LLM. A função dele é estabelecer uma conexão, formatar mensagens JSON-RPC, enviar solicitações e receber respostas.

Os termos “host MCP” e “cliente MCP” às vezes são usados como sinônimos. No entanto, essa é uma distinção útil, porque um host, como o Perplexity, pode orquestrar vários clientes MCP ao mesmo tempo. Um fluxo de trabalho de IA complexo pode exigir acesso a dezenas ou até centenas de servidores MCP diferentes, e cada um usará uma conexão separada.

Diagrama de um host MCP, como o Perplexity, orquestrando três clientes MCP, cada um conectado ao próprio servidor MCP, como um banco de dados, arquivos ou uma API externa.

O servidor expõe todas as ferramentas que a ferramenta baseada em IA pode usar. Do ponto de vista da arquitetura, o servidor MCP interpreta a solicitação recebida e, quando necessário, se conecta às primitivas solicitadas.

Os servidores MCP podem dar acesso a três categorias de primitivas:

Ferramentas: são, essencialmente, funcionalidades de software externas. Em uma abordagem tradicional baseada em APIs, um aplicativo de análise da web poderia recuperar dados usando uma solicitação formatada para um servidor externo. Na arquitetura MCP, todas as funcionalidades de terceiros de um provedor ficam disponíveis por meio de uma única conexão, e as solicitações são criadas seguindo regras de formatação padrão.
Recursos: recursos são fontes de dados que fornecem contexto somente leitura. Esquemas de banco de dados são um bom exemplo. O servidor MCP expõe as diversas fontes de informação disponíveis para o host. Se o host consultar o banco de dados, por exemplo, com uma busca SQL gerada por um LLM, isso é considerado uma solicitação de ferramenta.
Prompts: são modelos de prompt reutilizáveis que ajudam os LLMs a realizar tarefas específicas. Um usuário ou host chama um prompt em vez de uma ferramenta porque precisa de instruções prontas para concluir uma tarefa. Muitas vezes, tarefas predefinidas em um aplicativo host, como as opções “revisar código” ou “analisar dados”, são armazenadas como prompts que o usuário pode selecionar.

Também vale observar que MCP e API não são tecnologias mutuamente exclusivas. O servidor MCP pode expor chamadas de API disponíveis em resposta a uma solicitação de descoberta. O ponto principal é que cabe ao provedor do MCP mantê-las, não ao cliente.

A camada de dados na arquitetura MCP é o conjunto de regras que define como solicitações, respostas e notificações são formatadas. A linguagem padrão das mensagens é JSON-RPC.

Toda arquitetura MCP segue um processo básico de (1) inicialização e descoberta pelo host, (2) resposta do servidor MCP e (3) chamada pelo host (às vezes decidida pelo LLM), em que cada etapa corresponde a uma mensagem JSON separada.

Diagrama da camada de dados do MCP: um usuário envia um prompt ao aplicativo host, onde o LLM trabalha com o cliente MCP; o cliente envia uma solicitação ao servidor MCP (ferramentas, recursos, prompts) e recebe um resultado, e o host retorna uma resposta ao usuário.

Vejamos como funciona a descoberta de ferramentas por meio de dois exemplos (eles também podem se aplicar a recursos ou prompts):

Descobrir ferramentas antes da geração do LLM: o host inicia o cliente MCP, que envia uma solicitação tools/list (a lista de ferramentas disponíveis do servidor MCP). O LLM analisa essa lista durante o processo de geração e determina se uma ferramenta, um recurso ou um prompt específico é necessário.
Dar ao LLM a opção de fazer uma busca: em um sistema agêntico, o host adiciona uma opção de descoberta, como search-tools, à entrada de contexto, e o LLM pode solicitar uma busca, se necessário.

As ferramentas, que em geral são funcionalidades de aplicativos externos, normalmente são selecionadas pelo LLM ou pelo host. Recursos e prompts costumam ser solicitados a pedido do usuário ou pelo host.

Veja como é uma solicitação tools/list a um servidor MCP em um aplicativo de notas fictício:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Neste exemplo, “id”:101 identifica a solicitação por meio de um ID para que o cliente possa associar as respostas, e o campo “params” contém informações adicionais sobre o cliente, como o nome do cliente (notes-app-client) e suas capacidades.

Em resposta, o servidor MCP retorna as definições das ferramentas, que incluem os nomes das ferramentas disponíveis e os detalhes associados. Por exemplo, a lista pode incluir uma ferramenta add-task que permite ao aplicativo de notas criar tarefas em um aplicativo de gerenciamento de tarefas ou de calendário conectado, atribuindo a cada tarefa um título e uma prioridade.

Veja como poderia ser uma solicitação:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

O campo “method” informa ao servidor MCP que se trata de uma chamada de ferramenta, “name” especifica qual ferramenta chamar e “arguments” fornece as entradas necessárias.

Se a camada de dados é o quê da conexão entre um cliente e um servidor MCP, a camada de transporte é o como. Ela define a forma como as mensagens trafegam: o canal específico e as regras que determinam como solicitações e respostas são entregues.

O MCP tem dois caminhos de transporte:

Entrada/saída padrão: usada quando o servidor MCP é executado no mesmo ambiente local que o aplicativo host. O cliente grava a solicitação JSON na entrada padrão do servidor. O servidor a lê, executa a operação solicitada e grava a resposta na saída padrão.
Streamable HTTP: quando o servidor MCP é executado fora do aplicativo host, o cliente MCP envia solicitações ao servidor usando HTTP POST. O servidor responde com uma única mensagem JSON ou com um fluxo Server-Sent Events (SSE), um canal persistente de “escuta” que permite retornar várias mensagens ao longo do tempo.

A arquitetura MCP multilocatário é um tipo de implementação capaz de atender a vários usuários (locatários) simultaneamente.

Aqui, um locatário pode ser uma pessoa, um grupo de pessoas ou uma organização. A implementação pode envolver a execução de um servidor MCP separado para cada locatário, o acesso a um único servidor compartilhado ou a colocação de um conjunto de servidores por trás de um gateway central. Quando um gateway é usado, ele encaminha as solicitações aos endpoints corretos com base na identidade do usuário ou na natureza da solicitação.

Ela funciona com base no mesmo princípio básico da arquitetura MCP padrão, mas as solicitações de cada usuário operam em seu próprio espaço de trabalho (mesmo que isso envolva recursos compartilhados) e são autenticadas separadamente. É comum em cenários corporativos, e recursos compartilhados costumam ser preferidos porque executar vários servidores MCP seria desnecessariamente caro.

Como é uma solicitação MCP de ponta a ponta na prática? Há oito etapas principais, cada uma envolvendo um componente distinto da arquitetura.

Fluxograma de uma solicitação MCP de ponta a ponta em oito etapas: descoberta de ferramentas, entrada do usuário, processamento pelo modelo, seleção de ferramenta, solicitação, execução da ferramenta, resultado e geração da resposta.

Veja como é uma chamada de ferramenta MCP na prática, usando o exemplo anterior de um aplicativo de notas conectado a um serviço de gerenciamento de tarefas:

Descoberta de ferramentas: o aplicativo de notas (host) usa seu cliente MCP para solicitar as ferramentas disponíveis no servidor por meio de uma solicitação tools/list. O servidor retorna os nomes, as descrições e as entradas esperadas, incluindo as da ferramenta add-task. Isso pode acontecer antes de você enviar um prompt.
Entrada do usuário: você envia uma solicitação ao aplicativo de notas baseado em LLM pelo chatbot do aplicativo, como: “Crie uma tarefa no meu calendário para revisar meu novo rascunho com prioridade média.”
Processamento pelo modelo: o host envia sua solicitação e as definições de ferramentas relevantes ao LLM.
Seleção de ferramenta: o LLM gera uma solicitação de ferramenta estruturada, especificando a ferramenta e suas entradas: add-task com title: Revisar o rascunho e priority: Média. O host verifica se a ação é permitida e repassa a solicitação ao cliente MCP, que envia uma mensagem JSON-RPC.
Solicitação: o cliente MCP envia uma solicitação tools/call ao seu servidor MCP.
Execução da ferramenta: o servidor MCP chama a API do aplicativo de gerenciamento de tarefas para criar uma nova tarefa com o título e a prioridade especificados.
Retorno do resultado: o servidor envia o resultado de volta ao cliente MCP, que o repassa ao host. O host o adiciona às informações fornecidas ao LLM.
Geração da resposta: o LLM usa o resultado para gerar uma resposta para o usuário, como “Criei uma tarefa para revisar o rascunho com prioridade média.”

O MCP e a arquitetura de API tradicional costumam ser confundidos, mas são tecnologias complementares. O MCP foi projetado especificamente para aplicativos baseados em IA. Ele supera o alto custo de manutenção de implementar e gerenciar várias conexões de API fixas no código.

Ao fornecer a um aplicativo host uma única conexão por provedor de funcionalidade ou recurso interno, o MCP ajuda a resolver o problema da entrada de contexto inchada (com a lista de todas as APIs) ou de scripts limitados de aplicativos baseados em APIs.

Em vez disso, os MCPs podem expor APIs (ou, mais precisamente, a funcionalidade que chama APIs) como parte da lista de ferramentas. Sempre que um provedor atualiza o aplicativo e há uma nova API, ou quando a documentação muda, ele só precisa atualizar o servidor MCP. Nenhuma alteração de código é necessária no lado do aplicativo host.

A segurança do MCP tem sido tema de muito debate desde o seu lançamento. Embora seja geralmente considerada uma tecnologia segura, há vários riscos de segurança, muitos dos quais são mais evidentes em implementações de arquitetura complexas.

A arquitetura MCP apresenta as seguintes vulnerabilidades potenciais:

Injeção de prompt: um usuário insere um prompt malicioso em dados externos, que o modelo de IA interpreta erroneamente como uma instrução.
Acesso com privilégios excessivos: os servidores MCP podem expor um grande número de ferramentas a um modelo de IA, o que pode aumentar o potencial de problemas de segurança (o raio de impacto).
Vazamentos acidentais de dados: implementações mal configuradas podem fazer com que informações confidenciais, como chaves de API ou credenciais de banco de dados, sejam repassadas a um LLM.
Manipulação do sistema local: servidores MCP locais são tão vulneráveis a problemas do sistema local, como scripts maliciosos, quanto qualquer outro aplicativo, com o agravante de que podem ter efeitos nocivos em cascata sobre sistemas de IA agêntica.

Nenhum desses problemas é insuperável. Muitas vezes, medidas já estabelecidas são tudo o que é necessário para garantir a segurança do sistema. Medidas como manter um humano no circuito, aplicar controles rigorosos sobre dados confidenciais e proteger contra ataques ao servidor são práticas comuns.

O MCP provou ser um padrão aberto útil e popular entre os desenvolvedores. Ele resolve muitos dos problemas das APIs codificadas em aplicativos baseados em LLM e reduz substancialmente o trabalho de programação dos desenvolvedores.

Daqui para frente, a arquitetura subjacente de host e servidor do MCP quase certamente continuará a mesma. As inovações futuras se concentrarão em capacidades agênticas avançadas em fluxos de trabalho de várias etapas.

Além disso, serão necessárias proteções de segurança mais robustas à medida que essas funcionalidades agênticas forem implementadas, assim como uma arquitetura escalável, especialmente na camada de transporte, à medida que os sistemas de IA se tornarem mais amplos e complexos.

O que é a arquitetura MCP?

Componentes da arquitetura MCP: hosts, clientes e servidores

Host

Cliente

Servidor

O que é a camada de dados na arquitetura MCP?

O que é a camada de transporte na arquitetura MCP?

O que é a arquitetura MCP multilocatário?

Diagrama da arquitetura MCP: passo a passo

Qual é a diferença entre a arquitetura MCP e a arquitetura de API tradicional?

A arquitetura MCP é segura?

Qual é o futuro da arquitetura MCP?