MCP Series (02): Mergulho no Protocolo — Modelo Host/Cliente/Servidor e Comunicação JSON-RPC
Modelo de Três Camadas
O MCP separa responsabilidades em três papéis distintos:
Host
→ O aplicativo que executa a inferência LLM: Claude Desktop, Claude Code, Agente personalizado
→ Gerencia conexões com um ou mais Servidores MCP
→ Decide quais ferramentas/recursos expor ao LLM
Client (embutido no Host)
→ Mantém uma conexão 1:1 com um único Servidor MCP
→ Envia e recebe mensagens JSON-RPC 2.0
→ Rastreia o estado da sessão (capacidades negociadas, lista de ferramentas descobertas)
Server (processo independente)
→ Expõe três tipos de capacidades: Ferramentas / Recursos / Prompts
→ Comunica-se com os Clientes via stdio ou HTTP
→ Um Servidor pode ser conectado por múltiplos Hosts simultaneamente
Host é o que o usuário vê. Client é o adaptador de protocolo dentro do Host. Server é onde as ferramentas residem.
Três Tipos de Capacidade
Um Servidor MCP pode expor três tipos de capacidades:
Ferramentas → Ações que o LLM pode invocar
Exemplos: buscar Jira, executar SQL, enviar e-mail
O LLM decide quando chamá-las durante o raciocínio
Recursos → Fontes de dados que o LLM pode ler
Exemplos: status atual do sprint, árvore de arquivos do repositório
O Host decide quando injetá-los no contexto
Prompts → Modelos de prompt reutilizáveis
Exemplos: relatório de análise de bugs, modelo de revisão de código
O usuário ou o Host os invoca diretamente, preenchendo argumentos
Opções de Transporte
O Cliente e o Servidor se comunicam através de três mecanismos de transporte:
stdio (I/O padrão)
→ O Servidor é executado como um subprocesso; as mensagens fluem através de stdin/stdout
→ O mais simples; preferido para desenvolvimento local
→ Transporte padrão para integrações MCP do Claude Code
HTTP + SSE (Eventos Enviados pelo Servidor)
→ O Servidor é executado como um serviço HTTP
→ Cliente → Servidor: HTTP POST
→ Servidor → Cliente: fluxo SSE (suporta push iniciado pelo Servidor)
→ Adequado para Servidores remotos compartilhados entre múltiplos Clientes
HTTP Streamable (mais recente)
→ HTTP POST com fluxo SSE opcional
→ Suporta chamadas síncronas e push em streaming
→ Recomendado para implantações remotas desde a atualização da especificação de 2025
A demonstração deste artigo utiliza stdio — a maneira mais simples de observar o protocolo diretamente.
Troca Completa de Protocolo
Oito rodadas de mensagens JSON-RPC reais capturadas do servidor de demonstração, mostrando uma sessão completa de protocolo do início ao fim.
Etapa 1: inicializar (negociação de capacidade)
A primeira mensagem de cada sessão. Ambos os lados declaram o que suportam.
Cliente → Servidor (solicitação):
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2024-11-05",
"capabilities": {
"roots": {"listChanged": true},
"sampling": {}
},
"clientInfo": {"name": "demo-client", "version": "1.0.0"}
}
}
Servidor → Cliente (resposta):
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"protocolVersion": "2024-11-05",
"capabilities": {
"experimental": {},
"prompts": {"listChanged": false},
"resources": {"subscribe": false, "listChanged": false},
"tools": {"listChanged": false}
},
"serverInfo": {"name": "mcp-protocol-demo", "version": "1.13.1"}
}
}
tools.listChanged: false significa que a lista de ferramentas do Servidor é estática — o Cliente não precisa se inscrever para notificações de mudanças.
Após a conclusão de initialize, o Cliente envia uma notificação para confirmar a prontidão:
O entendimento do modelo MCP é crucial para empresas que utilizam LLMs, pois permite uma integração eficiente entre diferentes componentes. A implementação correta deste protocolo pode otimizar a comunicação e a utilização de recursos em aplicações de IA. Isso é especialmente relevante para empresas brasileiras que buscam modernizar suas operações com agentes de IA.
