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

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

Qualquer arquitetura MCP contém três componentes principais, em torno dos quais é construída: um anfitrião, um cliente e um servidor. A estrutura de comunicação do MCP é frequentemente descrita como sendo 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 (os pedidos MCP são enviados em JSON-RPC 2.0). A camada de transporte transporta essas mensagens, utilizando Streaming HTTP para ligações externas.

A arquitetura MCP é uma estrutura de servidor que implementa o Model Context Protocol, uma norma aberta para ligar modelos de IA a ferramentas, a recursos como bases de dados e a prompts que alargam o contexto de entrada. Estes elementos são designados coletivamente por “primitivas”. Em última análise, a arquitetura MCP permite que os LLM descubram que ferramentas estão disponíveis e executem fluxos de trabalho, sem necessidade de atualizações regulares do lado do cliente.

Diagrama da arquitetura MCP: uma aplicação de IA troca pedidos com um servidor MCP, que disponibiliza ferramentas, recursos e prompts.

Desde que foi introduzida pela Anthropic, a arquitetura MCP passou a ser amplamente utilizada em fluxos de trabalho de IA. Isto deve-se, em grande parte, ao facto de substituir sistemas com maior exigência de manutenção, como os construídos em torno de várias ligações de API, sem sacrificar o desempenho. Como toda a funcionalidade disponível se encontra por trás do servidor MCP, é necessária apenas uma ligação, e as atualizações e novidades ficam imediatamente disponíveis para a aplicação cliente.

O MCP proporciona aos LLM uma forma de descobrir e chamar as ferramentas, os prompts e os recursos que têm à sua disposição, seja no sistema local da aplicação anfitriã, seja a partir de um fornecedor externo.

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

Diagrama dos componentes da arquitetura MCP: um anfitrião que contém um LLM, um orquestrador e um cliente liga-se a um servidor MCP em dois passos, primeiro a descoberta e depois os pedidos, e o servidor MCP disponibiliza ferramentas, recursos e prompts.

Isto contrasta com a arquitetura personalizada baseada em APIs, que tem sido a norma no desenvolvimento de software, em que as funcionalidades externas à aplicação tinham de ser chamadas através de ligações dedicadas, com pedidos formatados com precisão.

A aplicação anfitriã é a plataforma central de orquestração e liga-se a um LLM. Ferramentas conhecidas como o Perplexity e o Claude Desktop podem funcionar como anfitriões num sistema MCP.

Num fluxo de trabalho simples, o utilizador faz uma pergunta através da interface de chat. O componente orquestrador do anfitrião acrescenta então contexto à pergunta, indicando ao LLM que primitivas MCP estão disponíveis, juntamente com uma descrição das respetivas capacidades.

O cliente é um componente de software da aplicação de IA. O MCP fornece uma interface padrão para que o cliente comunique com servidores MCP internos e externos, com base nas instruções do anfitrião ou do LLM. A sua função é estabelecer uma ligação, formatar mensagens JSON-RPC, enviar pedidos e receber respostas.

Os termos “anfitrião MCP” e “cliente MCP” são, por vezes, usados indistintamente. No entanto, trata-se de uma distinção útil, porque um anfitrião, como o Perplexity, pode orquestrar vários clientes MCP em simultâneo. Um fluxo de trabalho de IA complexo pode exigir acesso a dezenas ou até centenas de servidores MCP distintos, e cada um utilizará uma ligação separada.

Diagrama de um anfitrião MCP, como o Perplexity, a orquestrar três clientes MCP, cada um ligado ao seu próprio servidor MCP, como uma base de dados, ficheiros ou uma API externa.

O servidor expõe todas as ferramentas que a ferramenta baseada em IA pode utilizar. Do ponto de vista arquitetónico, o servidor MCP interpreta o pedido recebido e, quando necessário, liga-se às primitivas solicitadas.

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

Ferramentas: são, essencialmente, funcionalidades de software externas. Numa abordagem tradicional baseada em APIs, uma aplicação de análise web poderia obter dados através de um pedido formatado a um servidor externo. Na arquitetura MCP, todas as funcionalidades de terceiros de um fornecedor estão disponíveis através de uma única ligação, e os pedidos são criados segundo regras de formatação padrão.
Recursos: os recursos são fontes de dados que fornecem contexto só de leitura. Os esquemas de bases de dados são um bom exemplo. O servidor MCP expõe as várias fontes de informação disponíveis para o anfitrião. Se o anfitrião consultar a base de dados, por exemplo, com uma pesquisa SQL gerada por um LLM, isso é considerado um pedido de ferramenta.
Prompts: são modelos de prompts reutilizáveis que ajudam os LLM a realizar tarefas específicas. Um utilizador ou anfitrião chama um prompt em vez de uma ferramenta quando precisa de instruções prontas para concluir uma tarefa. Muitas vezes, as tarefas predefinidas numa aplicação anfitriã, como a opção de “rever código” ou “analisar dados”, são armazenadas como prompts que o utilizador pode selecionar.

Vale também a pena referir que MCP e API não são tecnologias mutuamente exclusivas. O servidor MCP pode expor chamadas de API que ficam disponíveis em resposta a um pedido de descoberta. O essencial é que cabe ao fornecedor do MCP mantê-las, e não ao cliente.

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

Todas as arquiteturas MCP seguem um processo básico de (1) inicialização e descoberta pelo anfitrião, (2) resposta pelo servidor MCP e (3) chamada pelo anfitrião (por vezes decidida pelo LLM), sendo cada fase representada por uma mensagem JSON separada.

Diagrama da camada de dados do MCP: um utilizador envia um prompt à aplicação anfitriã, onde o LLM trabalha com o cliente MCP; o cliente envia um pedido ao servidor MCP (ferramentas, recursos, prompts) e recebe um resultado, e o anfitrião devolve uma resposta ao utilizador.

Vejamos como funciona a descoberta de ferramentas através de dois exemplos (que também se podem aplicar a recursos ou prompts):

Descobrir ferramentas antes da geração pelo LLM: o anfitrião inicia o cliente MCP, que envia um pedido tools/list (a lista de ferramentas disponíveis do servidor MCP). O LLM analisa esta lista durante o processo de geração e determina se é necessária uma determinada ferramenta, recurso ou prompt.
Dar ao LLM a opção de executar uma pesquisa: num sistema agêntico, o anfitrião adiciona uma opção de descoberta, como search-tools, à entrada de contexto, e o LLM pode pedir uma pesquisa, se necessário.

As ferramentas, que são, de um modo geral, funcionalidades de aplicações externas, são normalmente selecionadas pelo LLM ou pelo anfitrião. Os recursos e os prompts são normalmente solicitados a pedido do utilizador ou pelo anfitrião.

Eis o aspeto de um pedido tools/list a um servidor MCP a partir de uma aplicação de notas imaginária:

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 o pedido através de um ID, para que o cliente possa fazer corresponder as respostas, e o campo “params” contém informações adicionais sobre o cliente, como o nome do cliente (notes-app-client) e as capacidades.

Em resposta, o servidor MCP devolve as definições das ferramentas, que incluem os nomes das ferramentas disponíveis e os respetivos detalhes. Por exemplo, a lista pode incluir uma ferramenta add-task que permite à aplicação de notas criar tarefas numa aplicação de gestão de tarefas ou de calendário ligada, atribuindo a cada tarefa um título e uma prioridade.

Eis o aspeto que um pedido poderia ter:

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” indica ao servidor MCP que se trata de uma chamada de ferramenta, “name” especifica a ferramenta a chamar e “arguments” fornece os dados de entrada necessários.

Se a camada de dados é o quê da ligação entre um cliente e um servidor MCP, a camada de transporte é o como. Define a forma como as mensagens circulam: o canal específico e as regras que determinam como os pedidos e as respostas são entregues.

O MCP tem dois caminhos de transporte:

Entrada/saída padrão: é utilizado quando o servidor MCP é executado no mesmo ambiente local que a aplicação anfitriã. O cliente escreve o pedido JSON na entrada padrão do servidor. O servidor lê-o, executa a operação solicitada e escreve a resposta na saída padrão.
Streamable HTTP: quando o servidor MCP é executado fora da aplicação anfitriã, o cliente MCP envia pedidos ao servidor através de HTTP POST. O servidor responde com uma única mensagem JSON ou com um fluxo Server-Sent Events (SSE), um canal de “escuta” persistente que lhe permite devolver várias mensagens ao longo do tempo.

A arquitetura MCP multi-inquilino é um tipo de implementação que consegue servir vários utilizadores (inquilinos) em simultâneo.

Neste caso, um inquilino pode ser uma pessoa, um grupo de pessoas ou uma organização. A implementação pode passar por executar um servidor MCP separado para cada inquilino, dar acesso a um único servidor partilhado ou colocar um conjunto de servidores por trás de um gateway central. Quando se utiliza um gateway, este encaminha os pedidos para os endpoints corretos com base na identidade do utilizador ou na natureza do pedido.

Funciona segundo o mesmo princípio básico da arquitetura MCP padrão, mas os pedidos de cada utilizador são processados no seu próprio espaço de trabalho (mesmo que isso implique recursos partilhados) e autenticados separadamente. É comum em cenários empresariais, e os recursos partilhados são frequentemente preferidos, porque executar vários servidores MCP seria desnecessariamente dispendioso.

Como é, na prática, um pedido MCP de ponta a ponta? Há oito fases principais, cada uma das quais envolve um componente distinto da arquitetura.

Fluxograma de um pedido MCP de ponta a ponta em oito passos: descoberta de ferramentas, entrada do utilizador, processamento pelo modelo, seleção da ferramenta, pedido, execução da ferramenta, resultado e geração da resposta.

Eis como funciona, na prática, uma chamada de ferramenta MCP, utilizando o exemplo anterior de uma aplicação de notas ligada a um serviço de gestão de tarefas:

Descoberta de ferramentas: a aplicação de notas (anfitrião) utiliza o seu cliente MCP para solicitar as ferramentas disponíveis do servidor através de um pedido tools/list. O servidor devolve os respetivos nomes, descrições e dados de entrada esperados, incluindo os da ferramenta add-task. Isto pode acontecer antes de submeter um prompt.
Entrada do utilizador: submete um pedido à aplicação de notas baseada em LLM através do chatbot integrado, como, por exemplo: “Cria uma tarefa no meu calendário para rever o meu novo rascunho, com prioridade média.”
Processamento pelo modelo: o anfitrião envia o seu pedido e as definições das ferramentas relevantes para o LLM.
Seleção da ferramenta: o LLM gera um pedido de ferramenta estruturado, especificando a ferramenta e os respetivos dados de entrada: add-task com title: Rever o rascunho e priority: Média. O anfitrião verifica se a ação é permitida e passa o pedido ao cliente MCP, que envia uma mensagem JSON-RPC.
Pedido: o cliente MCP envia um pedido tools/call ao respetivo servidor MCP.
Execução da ferramenta: o servidor MCP chama a API da aplicação de gestão de tarefas para criar uma nova tarefa com o título e a prioridade especificados.
Devolução do resultado: o servidor envia o resultado de volta ao cliente MCP, que o passa ao anfitrião. O anfitrião acrescenta-o às informações fornecidas ao LLM.
Geração da resposta: o LLM utiliza o resultado para gerar uma resposta para o utilizador, como “Criei uma tarefa para rever o rascunho, com prioridade média.”

O MCP e a arquitetura de API tradicional são frequentemente confundidos, mas são tecnologias complementares. O MCP foi concebido especificamente para aplicações baseadas em IA. Ultrapassa o elevado esforço de manutenção associado à implementação e gestão de várias ligações de API codificadas de forma fixa.

Ao fornecer a uma aplicação anfitriã uma única ligação por fornecedor de funcionalidades ou recurso interno, o MCP ajuda a resolver o problema de uma entrada de contexto sobrecarregada (com a lista de todas as APIs) ou de scripts de aplicações baseados em APIs limitados.

Em vez disso, os MCP podem expor APIs (ou, mais precisamente, a funcionalidade que chama as APIs) como parte da sua lista de ferramentas. Sempre que um fornecedor atualiza a sua aplicação e surge uma nova API, ou se a documentação muda, basta atualizar o servidor MCP. Não são necessárias alterações de código do lado da aplicação anfitriã.

A segurança do MCP tem sido objeto de muito debate desde a sua introdução. Embora seja geralmente considerada uma tecnologia segura, existem 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 potenciais vulnerabilidades:

Injeção de prompts: um utilizador insere um prompt malicioso em dados externos, que o modelo de IA interpreta erradamente 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).
Fugas de dados acidentais: implementações mal configuradas podem fazer com que informações sensíveis, como chaves de API ou credenciais de bases de dados, sejam transmitidas a um LLM.
Manipulação do sistema local: os servidores MCP locais são tão vulneráveis a problemas do sistema local, como scripts maliciosos, quanto quaisquer outras aplicações, com o problema adicional de poderem ter efeitos nocivos a jusante em sistemas de IA agênticos.

Nenhum destes problemas é insuperável. Muitas vezes, bastam medidas estabelecidas para garantir a segurança do sistema. Medidas como garantir a intervenção humana no processo, aplicar controlos rigorosos aos dados sensíveis e proteger contra ataques ao servidor são práticas comuns.

O MCP provou ser uma norma aberta útil e popular entre os programadores. Ultrapassa muitos dos problemas das APIs codificadas de forma fixa em aplicações baseadas em LLM e reduz substancialmente o trabalho de programação que lhes é exigido.

No futuro, a arquitetura subjacente de anfitrião e servidor do MCP vai, quase de certeza, manter-se igual. As inovações futuras vão centrar-se em capacidades agênticas avançadas em fluxos de trabalho com vários passos.

Além disso, serão necessárias salvaguardas de segurança mais robustas à medida que essas funcionalidades agênticas forem implementadas, bem como uma arquitetura escalável, sobretudo na camada de transporte, à medida que os sistemas de IA se tornam mais abrangentes e complexos.

O que é a arquitetura MCP?

Componentes da arquitetura MCP: anfitriões, clientes e servidores

Anfitrião

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 multi-inquilino?

Diagrama da arquitetura MCP: explicação passo a passo

Em que difere a arquitetura MCP da arquitetura de API tradicional?

A arquitetura MCP é segura?

O que se segue para a arquitetura MCP?