Conheça os três pilares da arquitetura MCP e entenda como Host, Client e Server trabalham juntos para conectar IA ao mundo real.
O Host é a aplicação onde o modelo de IA efetivamente roda. É o ponto de partida de tudo: a interface que o usuário vê, o ambiente que contém o modelo e o local onde a comunicação com o mundo externo é iniciada. Sem o Host, o modelo não tem onde existir — ele é a "casa" da IA.
O Host é a aplicação anfitriã que hospeda o modelo de IA e gerencia todo o ciclo de vida da interação. Ele é responsável por iniciar a comunicação, exibir resultados ao usuário e coordenar os Clients que se conectam aos Servers. Exemplos concretos de Hosts incluem:
Aplicação oficial da Anthropic que roda o Claude localmente com suporte nativo a MCP.
IDE que integra modelos de IA para auxiliar na programação, podendo atuar como Host MCP.
Aplicação interna customizada que embute um modelo de IA para automação de processos.
O conceito de Host no MCP foi inspirado na arquitetura do Language Server Protocol (LSP), criado pela Microsoft para editores de código. Assim como no LSP, onde o editor (VS Code, Neovim, etc.) é o host que se comunica com servidores de linguagem, no MCP o Host é a aplicação que contém o modelo e orquestra a comunicação. Essa escolha arquitetural permite que qualquer aplicação se torne um Host MCP — de assistentes pessoais a plataformas empresariais de larga escala.
O Client é o mensageiro da arquitetura MCP. Ele vive dentro do Host e é responsável por traduzir as necessidades do modelo em requisições padronizadas que os Servers conseguem entender. Cada Client mantém uma conexão dedicada com um Server específico, e um único Host pode conter múltiplos Clients — cada um conectado a um Server diferente.
O Client gerencia o ciclo de vida da conexão entre o Host e um Server. Suas responsabilidades incluem: iniciar e encerrar conexões, enviar requisições no formato MCP, receber e processar respostas, lidar com erros e timeouts, e manter o estado da sessão. O Client abstrai toda a complexidade da comunicação — o modelo não precisa saber como falar com cada ferramenta, apenas pede o que precisa e o Client traduz. Um Host como o Claude Desktop pode ter simultaneamente um Client conectado ao GitHub, outro ao PostgreSQL e outro ao sistema de arquivos local.
O Client é como um tradutor simultâneo entre o modelo e as ferramentas. Imagine que o modelo fala "português" e cada ferramenta fala um idioma diferente — o banco de dados fala "SQL", o GitHub fala "API REST", o sistema de arquivos fala "comandos do SO". O Client traduz tudo para o formato padronizado MCP, garantindo que a comunicação flua perfeitamente sem que nenhum dos lados precise aprender o idioma do outro.
O Server é o componente que efetivamente expõe capacidades ao modelo de IA. Ele disponibiliza Tools (ferramentas que executam ações), Resources (dados que podem ser lidos) e Prompts (templates reutilizáveis de interação). Cada Server é especializado em um domínio específico: existe um Server para GitHub, outro para banco de dados, outro para e-mail, e assim por diante.
O Server MCP é um programa que expõe capacidades padronizadas para serem consumidas por Clients. Ele faz a ponte entre o protocolo MCP e os sistemas externos reais. Por exemplo, um Server de GitHub recebe uma requisição MCP do tipo "liste os pull requests abertos" e a traduz em chamadas à API do GitHub, retornando o resultado no formato padronizado. A filosofia é que cada Server seja focado e especializado — um Server para cada domínio, cada um fazendo bem uma única coisa.
Agora que você conhece os três pilares — Host, Client e Server — é hora de ver como eles trabalham juntos em um fluxo real de ponta a ponta. Desde o momento em que o usuário faz uma pergunta até a resposta final, cada componente desempenha um papel preciso nessa orquestração.
O fluxo MCP segue uma cadeia bem definida: o usuário faz uma solicitação ao Host, o modelo dentro do Host identifica que precisa de dados ou ações externas, o Client traduz essa necessidade em uma requisição MCP padronizada, o Server executa a ação no sistema externo, e o resultado faz o caminho de volta até o modelo, que formula a resposta final ao usuário. Tudo isso acontece de forma transparente — o usuário não precisa saber que múltiplos sistemas foram consultados nos bastidores.
O usuário envia uma mensagem ao Host. Exemplo: "Quais são os pull requests abertos no meu repositório?"
O modelo de IA dentro do Host analisa a pergunta e determina que precisa acessar o GitHub para respondê-la. Ele identifica qual tool do Server MCP deve ser chamada.
O Client do Host traduz a necessidade do modelo em uma requisição MCP padronizada e a envia ao Server de GitHub.
O Server de GitHub recebe a requisição, chama a API do GitHub, obtém a lista de pull requests abertos e formata o resultado.
O Server envia a resposta padronizada de volta ao Client, que a repassa ao modelo dentro do Host.
O modelo processa os dados recebidos e formula uma resposta natural ao usuário: "Você tem 3 PRs abertos: #42 (fix login), #38 (add tests), #35 (update docs)."
Para consolidar a arquitetura na sua mente, vamos construir um mapa mental da estrutura MCP. Visualizar como as peças se encaixam é fundamental para entender onde cada componente começa e termina, e como a informação flui entre eles.
A arquitetura MCP segue uma hierarquia clara de contenção e conexão:
O Host contém o modelo e os Clients. Cada Client se conecta a exatamente um Server. Cada Server se conecta a um ou mais sistemas externos. Essa separação garante modularidade, segurança e escalabilidade.
Pense na arquitetura MCP como um escritório moderno. O Host é o prédio do escritório onde tudo acontece. O modelo de IA é o diretor que toma decisões. Os Clients são os assistentes executivos — cada um especializado em lidar com um fornecedor diferente. E os Servers são os fornecedores externos (banco, correio, TI) que executam os serviços solicitados. O diretor não liga diretamente para cada fornecedor — ele pede ao assistente certo, que sabe exatamente como se comunicar com aquele fornecedor.
A teoria ganha vida com exemplos concretos. Vamos analisar dois cenários reais de uso da arquitetura MCP — um para desenvolvedores e outro para equipes de negócio — para ver como Host, Client e Server se articulam na prática.
A beleza da arquitetura MCP é que ela funciona da mesma forma independente do cenário. Seja um programador pedindo análise de código ou uma equipe de vendas consultando métricas, o fluxo Host → Client → Server permanece idêntico. O que muda são os Servers conectados e as Tools disponíveis — mas a arquitetura, o protocolo e o padrão de comunicação são sempre os mesmos. Essa consistência é o que torna o MCP tão poderoso.
Um desenvolvedor abre o Claude Desktop e pede: "Analise os últimos commits do meu repo e sugira melhorias."
Host: Claude Desktop (aplicação com o modelo Claude)
Client: Client MCP interno do Claude Desktop
Server: Server MCP de GitHub (acessa a API do GitHub)
Fluxo: Claude identifica necessidade → Client envia requisição ao Server GitHub → Server consulta commits via API → resultado retorna → Claude apresenta análise com sugestões
Um gerente de vendas usa a plataforma interna da empresa e pergunta: "Qual foi o faturamento do último trimestre por região?"
Host: Aplicação interna da empresa (com modelo de IA integrado)
Client: Client MCP configurado na aplicação
Server: Server MCP de PostgreSQL (conecta ao banco de dados)
Fluxo: Modelo identifica necessidade de dados → Client envia requisição ao Server PostgreSQL → Server executa query SQL → resultado retorna → Modelo apresenta relatório formatado com dados por região
Cuidado com permissões! O fato de um Server MCP poder executar ações em sistemas externos torna o controle de acesso fundamental. Cada Server deve ter apenas as permissões mínimas necessárias — o Server de GitHub não precisa de acesso ao banco de dados, e o Server de PostgreSQL não precisa de acesso ao GitHub. Sempre aplique o princípio do menor privilégio: conceda apenas as permissões estritamente necessárias para cada Server executar sua função.
Próximo Módulo: 1.4 — Vendo o MCP em Ação