Se você pesquisou "diagrama de arquitetura do model context protocol" esperando encontrar algo que realmente pudesse desenhar em um quadro branco e explicar para sua equipe, está no lugar certo. A maioria das explicações sobre MCP para em "ele conecta IA a ferramentas" ou parte direto para detalhes da especificação sem responder à questão arquitetural básica: o que se comunica com o quê, em que ordem e quem é responsável por cada parte.
Este artigo oferece a visão no nível de implementação. Não apenas definições.
A parte que a maioria das equipes aprende depois de lançar
- O MCP fica sobre as APIs — ele padroniza como os LLMs as descobrem e chamam, não as substitui.
- A arquitetura aberta de cliente-servidor significa que um host pode executar vários clientes, cada um se conectando de forma independente a um servidor diferente.
- O MCP define a interface de integração; controle de acesso, governança de dados e segurança são responsabilidades que você precisa implementar.
O que é o Model Context Protocol e por que a Anthropic o introduziu
O model context protocol é um protocolo aberto introduzido pela Anthropic em novembro de 2024. A definição da especificação oficial é precisa: MCP é uma forma padronizada de aplicações de IA se conectarem a fontes de dados, ferramentas e sistemas externos por meio de uma interface consistente, em vez de criar uma conexão personalizada para cada um deles.
Essa última parte é o ponto principal. Antes do MCP, cada equipe que conectava um LLM a uma ferramenta criava seu próprio adaptador. Formato diferente, abordagem de autenticação diferente, tratamento de erros diferente. Multiplique isso por dezenas de ferramentas e você terá dezenas de integrações isoladas que precisam ser mantidas separadamente. O padrão MCP existe para consolidar isso em um único formato de protocolo.
A Anthropic o introduziu, mas ele não é um produto exclusivo da Anthropic. A especificação do MCP é aberta, mantida publicamente e já adotada em IDEs, assistentes de programação, plataformas de IA e stacks corporativas de agentes. No primeiro trimestre de 2026, o mapa do ecossistema de protocolos da DigitalApplied identificou o MCP ao lado de A2A, ACP e UCP como quatro protocolos distintos com adoção relevante no mercado — o que significa que o MCP já não é mais uma curiosidade experimental. Ele faz parte de como os sistemas de agentes em produção estão realmente sendo construídos.
O model context protocol permite que qualquer aplicação de IA compatível acesse qualquer ferramenta ou fonte de dados compatível sem uma integração personalizada para cada par. Essa é toda a proposta de valor. Todo o resto decorre dela.
O modelo cliente-servidor por trás da arquitetura MCP
A especificação oficial do MCP descreve uma arquitetura de host-cliente-servidor em que cada host pode executar várias instâncias de cliente. Quatro componentes. Cada um é distinto.
Eis o que confunde as pessoas: os termos "cliente" e "servidor" têm um significado específico no MCP que nem sempre corresponde à forma como essas palavras são usadas em redes em geral. E "host" é uma terceira coisa completamente diferente, não apenas outra palavra para servidor. Vamos detalhá-los para que você possa, de fato, desenhar o diagrama.
Host MCP: a aplicação que executa o LLM
O host MCP é a aplicação que incorpora ou executa o modelo de linguagem de grande porte e inicia todo o processo. Pense no Claude Desktop, Cursor ou em uma aplicação de IA personalizada que sua equipe criou. O host é com o que o usuário realmente interage.
O host também é responsável pelo controle de acesso e pela governança de dados. Esse é um detalhe frequentemente ignorado, e ele importa em produção. O MCP não protege automaticamente os recursos. O host decide quais servidores podem ser conectados, qual escopo de dados cada cliente pode acessar e quem tem permissão para invocar quais ferramentas. Se você está implementando uma aplicação de IA que acessa sistemas sensíveis e ainda não pensou nessa camada, você lançou uma lacuna de governança.
Um host, vários clientes. Esse é o padrão.
Cliente MCP: o conector um a um dentro do host
Cada cliente MCP fica dentro do host e mantém uma conexão um a um com um único servidor MCP. Um cliente, um servidor. Essa é a restrição.
Mas um único host pode iniciar vários clientes simultaneamente, cada um apontando para um servidor diferente. Portanto, se o host precisar se comunicar com um servidor de banco de dados, um servidor GitHub e um servidor interno de tickets ao mesmo tempo, ele executará três clientes. Cada cliente gerencia seu próprio ciclo de vida de conexão, lida com seu próprio estado de sessão e se comunica de modo independente com seu respectivo servidor.
A distinção entre servidor e cliente importa aqui: o cliente não é o elemento voltado ao usuário. Ele é a camada de conexão dentro do host. Tratá-los como termos intercambiáveis é onde os diagramas começam a dar errado.
A checklist prática antes de configurar isso:
- Confirme que a aplicação host é compatível com várias conexões simultâneas de clientes
- Cada par cliente-servidor precisa de sua própria configuração de autenticação
- O ciclo de vida do cliente (inicialização, encerramento e tratamento de erros) é gerenciado pelo host
- Se um servidor ficar indisponível, apenas o cliente conectado a ele será afetado, não todo o host
Servidor MCP: expondo ferramentas, recursos e prompts
O servidor MCP é o processo independente que expõe capacidades ao cliente. É o que sua equipe cria (ou adota a partir de uma biblioteca existente de implementações de servidor MCP) quando quer dar a um LLM acesso a uma fonte de dados ou ferramenta interna.
Um servidor expõe três tipos de capacidades, conhecidos como primitivas: ferramentas, recursos e prompts. Abordaremos os três na próxima seção.
O servidor é executado de forma independente do host. Ele não precisa saber nada sobre qual host ou cliente se conecta a ele. Essa independência torna o ecossistema componível: você pode criar um servidor para sua instância interna do Confluence, e qualquer host MCP compatível poderá se conectar a ele. Sem um conector personalizado para cada aplicação de IA. O servidor apenas expõe suas capacidades; o cliente as descobre.
Do ponto de vista da decisão de desenvolvimento, é aqui que o trabalho real acontece. Quando equipes perguntam "como conectamos nosso assistente de IA às nossas ferramentas internas?", a resposta é: você cria ou adota um servidor MCP para cada ferramenta. As fontes de dados às quais seu LLM precisa acessar são empacotadas como recursos e ferramentas no lado do servidor.
Primitivas MCP: ferramentas, recursos e prompts explicados
A especificação MCP define três tipos de capacidades que os servidores expõem aos clientes. Elas são chamadas de primitivas e tornam o MCP útil para além de uma definição genérica de protocolo. Cada uma atende a uma finalidade diferente.
Entender as três é o que permite passar de "MCP conecta IA a ferramentas" para "estas são as capacidades que nosso servidor realmente expõe e o motivo".
Ferramentas e function calling no MCP
As ferramentas MCP são funções executáveis que o LLM pode invocar por meio do cliente. Se você já trabalhou com function calling na API da OpenAI, o padrão será familiar: você descreve uma função, o modelo de linguagem de grande porte decide quando chamá-la e ela é chamada com argumentos específicos.
O que o MCP padroniza é como os modelos de IA descobrem essas funções em diferentes servidores. Sem o MCP, cada servidor tem seu próprio formato de descoberta. Com o MCP, o cliente solicita que o servidor liste suas ferramentas disponíveis usando o mesmo formato de requisição, independentemente de qual seja o servidor. O LLM vê um esquema de ferramentas consistente, não importa quantos servidores estejam envolvidos.
Um exemplo prático: um servidor para GitHub expõe ferramentas como search_repository, get_file_contents e create_pull_request. O LLM consegue descobrir todas elas, entender seus parâmetros e executá-las por meio do cliente sem qualquer integração personalizada no lado do host. O servidor sustenta essas ferramentas com chamadas de API para o GitHub. O MCP fica sobre essas APIs; ele não as substitui.
O protocolo MCP também lida com o que acontece quando uma chamada de ferramenta falha, sofre limitação de taxa ou retorna uma resposta inesperada. Esse ciclo de vida fica na camada de protocolo, o que significa que o LLM não precisa gerenciá-lo diretamente.
Acesso a dados por meio de recursos MCP
Recursos são o mecanismo que os servidores MCP usam para expor dados estruturados ou não estruturados ao cliente. Enquanto as ferramentas executam ações, os recursos fornecem contexto. Uma ferramenta pode executar uma consulta no banco de dados; um recurso expõe o esquema para que o LLM possa receber contexto relevante antes de decidir o que consultar ou incluir dados diretamente em seu raciocínio.
Os recursos podem ser documentos, registros de banco de dados, conteúdo de arquivos, resultados de análises — qualquer coisa que forneça informações úteis ao LLM. O cliente os busca, e o servidor retorna os dados em um formato padronizado.
Isso importa para equipes que conectam aplicações de LLM a fontes de dados existentes. Em vez de escrever uma lógica de recuperação personalizada para cada fonte de dados, você encapsula a fonte em um servidor MCP e expõe os dados relevantes como recursos. O LLM pode consultá-los sem saber nada sobre o sistema de armazenamento subjacente.
Camada de transporte: como STDIO e HTTP+SSE movem mensagens entre cliente e servidor
A camada de transporte é o canal de comunicação entre o cliente MCP e o servidor. A especificação MCP usa JSON-RPC 2.0 como formato de mensagem em todos os transportes, o que significa que a estrutura de requisições e respostas é consistente independentemente da camada de transporte escolhida.
Dois transportes são definidos no protocolo principal: STDIO e HTTP com Server-Sent Events.
STDIO é o transporte local. O host inicia o servidor MCP como um subprocesso, e cliente e servidor se comunicam por fluxos de entrada e saída padrão. Isso é típico em implementações MCP locais, em que o servidor é executado na mesma máquina que o host. A maioria das integrações com IDEs (Cursor, extensões do VS Code) usa STDIO porque o servidor é um processo local. A configuração é simples; não há superfície de rede com que se preocupar.
HTTP+SSE é o transporte remoto. O servidor é executado como um processo separado, potencialmente em outra máquina ou ambiente, e a comunicação entre cliente MCP e servidor acontece por HTTP. Server-Sent Events lida com a direção de mensagens do servidor para o cliente, enquanto o cliente envia mensagens por HTTP POST convencional. É o que você usa quando o servidor está hospedado remotamente, compartilhado entre vários hosts ou implementado como um serviço.
As versões de protocolo para cada um são definidas na especificação, e os dois transportes não são intercambiáveis em tempo de execução. Você escolhe um deles no momento da implementação, e essa escolha traz consequências.
| Situação | Transporte | Por quê |
|---|---|---|
| Subprocesso local (plugin de IDE, aplicativo desktop) | STDIO | Mesma máquina, baixa sobrecarga, sem exposição à rede |
| Servidor remoto compartilhado (acesso para toda a equipe) | HTTP+SSE | Entre máquinas, acessível por vários hosts |
| Servidor implementado na nuvem | HTTP+SSE | Acessível pela rede por definição |
| Desenvolvimento/testes em máquina local | STDIO | Configuração mais simples, sem necessidade de autenticação |
🤔 Espere.
A seleção do transporte parece uma preferência de conectividade. Na verdade, é uma decisão de limite arquitetural. STDIO significa que seu servidor é executado na máquina do host MCP — isso define seu modelo de implementação, seu perímetro de segurança e se o servidor pode ser compartilhado com outros hosts. HTTP+SSE significa que seu servidor é acessível pela rede — o que abre questões de governança completamente diferentes. A escolha "simples" vem com compromissos arquiteturais associados.
Como a arquitetura MCP se compara a uma integração direta de API
O equívoco mais persistente que vejo é que o MCP substitui APIs. Não substitui. Vamos deixar claro o que ele realmente faz.
O MCP é uma camada de protocolo padrão que fica acima das APIs. Quando um servidor MCP expõe uma ferramenta como search_database, essa ferramenta é sustentada por uma chamada de API (ou por uma consulta ao banco de dados ou leitura de arquivo). O MCP padroniza como o LLM descobre a ferramenta e a invoca. A API subjacente continua existindo. O MCP apenas fornece uma interface consistente para chamá-la.
A analogia que funciona bem é o Language Server Protocol, usado por todos os principais editores de código. O LSP padronizou como os editores se comunicam com ferramentas de análise de linguagem. Antes do LSP, cada editor criava integrações personalizadas com cada servidor de linguagem. Depois do LSP, qualquer editor compatível se conecta a qualquer servidor de linguagem compatível. O MCP segue o mesmo padrão para aplicações de IA e ferramentas externas.
O problema de conectar sistemas de IA que o MCP resolve às vezes é chamado de problema de integração N×M. Sem um protocolo padrão, N aplicações de IA conectadas a M ferramentas exigem até N×M conectores personalizados. Com um padrão MCP, cada aplicação de IA implementa o MCP uma vez (no lado do cliente), cada ferramenta implementa o MCP uma vez (no lado do servidor), e qualquer par compatível pode se conectar.
📊 Na prática:
Sem MCP, conectar assistentes de IA a cinco ferramentas internas significa cinco camadas de integração personalizadas, cada uma com sua própria autenticação, tratamento de erros e mecanismo de descoberta — mantidas separadamente conforme qualquer uma das cinco ferramentas muda. Com MCP, um único cliente compatível no host se conecta aos cinco servidores usando o mesmo protocolo. Quando um servidor atualiza seu esquema de ferramentas, o cliente descobre a alteração pelo fluxo padrão de negociação de capacidades, não por uma atualização de adaptador sob medida.
Os sistemas externos de que seu LLM precisa — bancos de dados, APIs, armazenamentos de arquivos e serviços internos — não desaparecem por trás do MCP. Eles continuam lá. O MCP apenas evita que você escreva um conector único para cada aplicação de IA que precisa acessá-los.
Onde a arquitetura MCP se encaixa em fluxos de IA agêntica
Há outro equívoco que vale abordar diretamente: MCP não é um framework de agentes.
Um sistema agêntico precisa, no mínimo, de uma camada de planejamento (algo que decide o que fazer em seguida), uma camada de gerenciamento de memória ou contexto (algo que acompanha o que aconteceu) e uma camada de acesso a ferramentas (algo que se conecta a sistemas externos para executar ações). O MCP cuida da terceira. Ele não cuida das duas primeiras.
Ao criar agentes de IA, o framework de agentes acima do MCP é responsável pela lógica: qual objetivo perseguir, quais etapas executar, quando tentar novamente, quando desistir e como gerenciar o contexto em várias interações. O MCP gerencia como essas ferramentas e fontes de dados são acessadas depois que o framework decide acessá-las.
A relação é a seguinte: sistemas agênticos usam o MCP para alcançar ferramentas, não usam o MCP para executar agentes.
Essa distinção importa na fase de design dos sistemas agênticos. Quando seu fluxo começa a se comportar mal, você precisa saber se o problema está na lógica do agente (decisão errada, objetivo errado, gerenciamento de contexto inadequado) ou na camada de acesso a ferramentas (servidor errado, chamada com falha, parâmetro incorreto). Se você confundiu os dois, o diagnóstico se torna muito mais difícil.
Na prática, o fluxo fica acima do MCP na stack. O framework de agentes decide quando chamar uma ferramenta; o MCP gerencia como essa chamada é feita e como a resposta retorna. O comportamento de IA sensível ao contexto depende do framework de agentes para gerenciar o contexto; o MCP fornece apenas o mecanismo para buscar contexto adicional quando o framework solicita isso.
Um exemplo concreto: uma equipe de ferramentas para desenvolvedores em uma organização de engenharia de médio porte queria que seu assistente de programação com IA pesquisasse repositórios internos de código, acionasse execuções de CI/CD e criasse tickets de incidentes sem sair da IDE. Ela criou três servidores MCP, um para cada ferramenta, cada qual expondo ferramentas e recursos relevantes, e os conectou ao host da IDE por meio da camada de cliente. Os sistemas de IA na IDE agora chamam essas ferramentas. Mas a lógica que determina quando acionar uma execução de CI em vez de apenas exibir um alerta fica no framework de agentes acima de tudo isso. A comunicação entre os componentes de IA e os servidores é responsabilidade do MCP. O raciocínio sobre o que fazer não é.
Se você usa o AI Agent Builder e o MCP Server Builder da Latenode juntos, essa divisão fica visível no canvas: o servidor MCP expõe quais ferramentas estão disponíveis, e o fluxo do agente decide quando invocá-las. Essa separação não é apenas uma arquitetura limpa em um diagrama — é o que torna a depuração possível quando o agente faz uma chamada errada.
Responsabilidades de segurança e governança em uma implementação MCP
O MCP define a interface de integração. Ele não implementa sua política de segurança. Equipes que lançam sistemas conectados por MCP esperando que o protocolo cuide do controle de acesso descobrem isso em produção, geralmente em um momento inconveniente.
Estas são as responsabilidades que pertencem à sua implementação, não ao próprio MCP:
- Aplicação de controle de acesso (host)
O host decide a quais servidores MCP cada cliente pode se conectar e qual escopo cada conexão pode acessar. O MCP não fornece nenhum mecanismo integrado para impedir que um cliente se conecte a um servidor que não deveria alcançar. A aplicação de IA deve implementar essa verificação explicitamente antes de iniciar um cliente.
- Definição de escopo de dados por ferramenta e recurso (servidor)
O servidor é responsável por retornar apenas os dados que o solicitante está autorizado a visualizar. Se seu servidor MCP encapsula um banco de dados e um cliente envia uma consulta de recurso, o servidor deve aplicar acesso no nível de linha ou esquema antes de retornar resultados. O modelo de linguagem e a camada de cliente não têm visibilidade sobre se os dados retornados receberam o escopo adequado.
- Gerenciamento do ciclo de vida de autenticação (host e servidor)
Tokens OAuth, chaves de API e credenciais de serviço expiram. O host deve lidar com a renovação de tokens para clientes, e o servidor deve validar a autenticação em cada requisição, não apenas no momento da conexão. Um padrão comum de falha: a autenticação passa na inicialização, expira silenciosamente e começa a retornar erros 401 horas depois. O painel geralmente parece normal até que alguém perceba que os dados pararam de circular.
- Registro de auditoria (host e servidor)
O MCP não inclui uma trilha de auditoria integrada. Se você precisa de um registro de quais ferramentas foram chamadas, com quais argumentos, por qual cliente e o que foi retornado, precisa criar esse registro você mesmo, tanto no lado do servidor (para invocações de ferramentas) quanto no lado do host (para eventos de sessão).
- Isolamento de servidor (servidor)
Cada servidor MCP deve operar de forma independente, com seu próprio conjunto de credenciais e escopo de acesso. Um servidor com permissões amplas que seja comprometido expõe tudo dentro desse escopo. Se uma consulta apresentar problema em um servidor, ela não deve se propagar para os demais. O isolamento é uma decisão de arquitetura, não uma garantia do protocolo.
