Como Servidores MCP Lidam com Requisições
O Protocolo de Contexto de Modelo (Model Context Protocol - MCP) oferece ao Claude uma maneira padrão de acessar sistemas reais fora de sua própria janela de contexto.
//
Busque em todas as páginas da documentação
O Protocolo de Contexto de Modelo (Model Context Protocol - MCP) oferece ao Claude uma maneira padrão de acessar sistemas reais fora de sua própria janela de contexto.
Um servidor que fala MCP pode envolver um banco de dados, um sistema de tickets, um sistema de arquivos ou uma API interna.
Antes que qualquer uma dessas coisas seja útil, no entanto, um cliente e um servidor precisam concordar sobre o que o servidor pode fazer e como falar com ele.
Esse acordo, e tudo o que se segue, é o ciclo de vida da requisição que esta página detalha.
Entender o ciclo de vida é importante porque a maioria dos bugs em um novo servidor MCP não são bugs de ferramenta.
São bugs de ciclo de vida: uma ferramenta registrada tarde demais, uma capacidade nunca declarada, uma resposta formatada incorretamente para a etapa em que o cliente pensa que está.
Um servidor MCP é um programa que expõe um conjunto fixo de capacidades a um cliente através de um protocolo definido.
Essas capacidades se enquadram em três categorias: ferramentas que o cliente pode invocar, recursos que o cliente pode ler e prompts que o cliente pode buscar como modelos reutilizáveis.
O cliente é geralmente o próprio Claude, agindo através de um aplicativo como Claude Code, Claude Desktop ou uma integração personalizada construída no Agent SDK.
Pense no servidor como um recepcionista em um prédio com vários departamentos.
O recepcionista não faz o trabalho de todos os departamentos, ele apenas sabe qual sala lida com qual requisição e passa as coisas corretamente.
Um servidor MCP se comporta da mesma maneira: ele não precisa saber por que o Claude quer chamar uma ferramenta, apenas como rotear a chamada para o manipulador correto e retornar um resultado bem formatado.
O próprio ciclo de vida tem quatro etapas, em uma ordem fixa:
1. Conectar cliente abre um transporte (pipe stdio, ou sessão HTTP/SSE)
2. Negociar cliente e servidor trocam capacidades e versões suportadas
3. Trocar cliente lista/chama ferramentas, lê recursos, busca prompts
4. Desconectar transporte fecha, estado da sessão é desmanteladoNenhuma etapa pode ser pulada, e a etapa 3 não pode começar até que a etapa 2 termine com sucesso.
Conexão é específica do transporte, mas agnóstica do protocolo em sua intenção.
Via stdio, o cliente inicia o servidor como um subprocesso e se comunica com ele através da entrada e saída padrão.
Via HTTP/SSE, o cliente abre uma conexão de rede para um processo de servidor em execução, geralmente autenticando-se primeiro.
De qualquer forma, o objetivo desta etapa é o mesmo: estabelecer um canal pelo qual os dois lados possam trocar mensagens estruturadas.
Negociação de capacidade ocorre imediatamente após a conexão, antes que o cliente confie no servidor para qualquer outra coisa.
O cliente envia uma requisição de inicialização descrevendo o que ele suporta; o servidor responde com sua própria versão de protocolo suportada e um manifesto do que ele oferece, quais ferramentas existem, quais recursos são legíveis, quais prompts estão disponíveis.
Este é o ponto em que um cliente aprende "este servidor tem uma ferramenta search_tickets" ou "este servidor expõe um recurso config://settings".
Uma ferramenta que o servidor nunca registrou nesta troca efetivamente não existe para o cliente, não importa quão correto seja seu código de manipulador subjacente.
Esta é a fonte mais comum de bugs do tipo "minha ferramenta não aparece": o manipulador foi escrito, mas nunca conectado ao registro que o servidor anuncia durante a negociação.
Troca de requisições é onde o trabalho real acontece, e é em si um ciclo repetitivo de requisição/resposta.
O cliente envia uma requisição, nomeando uma ferramenta e seus argumentos, ou nomeando um URI de recurso, ou nomeando um modelo de prompt.
Cliente -> Servidor: call_tool("get_weather", {"city": "Denver"})
Servidor: roteia para o manipulador registrado para get_weather
Servidor -> Cliente: { "temperature": 61, "conditions": "clear" }O servidor roteia essa requisição para o manipulador correspondente, o executa e retorna uma resposta estruturada.
Cada chamada é independente no nível do protocolo; o servidor não assume nenhuma ordem entre uma chamada de ferramenta e a próxima, a menos que a própria lógica do servidor imponha uma.
Recursos se comportam de forma semelhante, mas são orientados à leitura: o cliente pede um URI, o servidor retorna o conteúdo; nenhum argumento além do próprio URI é tipicamente envolvido.
Prompts são modelos que o servidor devolve para o cliente preencher e usar, mais próximos de um trecho reutilizável do que de uma ação ao vivo.
Desconexão fecha o transporte e descarta qualquer estado por sessão que o servidor estava mantendo.
Um servidor bem construído trata cada sessão como descartável: se ele precisar lembrar algo além de uma única conexão, isso pertence a um armazenamento de dados real, não à memória vinculada ao transporte.
Em escala, o ciclo de vida interage com duas coisas que não aparecem em um exemplo simples: concorrência e estado.
Um único processo de servidor, especialmente um implantado via HTTP/SSE, pode manter muitas sessões de cliente abertas simultaneamente, cada uma tendo passado por sua própria negociação independentemente.
O servidor precisa manter as capacidades negociadas de cada sessão e qualquer estado com escopo de sessão separados; misturá-los entre clientes é um bug de correção, não apenas de desempenho.
O estado dentro de um manipulador de ferramenta também merece ser deliberado.
Uma ferramenta que lê e escreve em um sistema externo, uma linha de banco de dados, um arquivo, uma API, deve tratar cada invocação como uma requisição nova, mesmo que o recurso subjacente tenha estado, porque o próprio protocolo não oferece garantia sobre quantas vezes uma ferramenta será chamada ou em que ordem em relação a outras ferramentas.
| Abordagem | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| Manipuladores sem estado, estado vive externamente | Seguro sob clientes concorrentes, fácil de raciocinar | Requer um armazenamento de dados real ou API por trás da ferramenta | Servidores de produção com mais de um cliente |
| Estado de sessão em memória | Simples, rápido, sem dependência externa | Perdido na reinicialização, quebra sob múltiplas instâncias de servidor | Servidores de desenvolvimento locais, para um único usuário, stdio |
A segurança também segue diretamente do ciclo de vida.
Como a negociação ocorre antes que qualquer chamada de ferramenta seja confiável, um servidor HTTP/SSE que pula a autenticação no estágio de conexão não tem um ponto posterior no ciclo de vida onde possa adicionar essa verificação com segurança sem quebrar as suposições do protocolo.
É por isso que a autenticação para servidores remotos é tratada no momento da conexão, não dentro de manipuladores de ferramentas individuais.
O cliente ainda não sabe o que o servidor oferece. A negociação é onde o manifesto de ferramentas, recursos e prompts do servidor é enviado, então qualquer chamada tentada anteriormente não tem nada para rotear no lado do cliente.
Uma ferramenta é algo que o cliente invoca para realizar uma ação, que pode ter efeitos colaterais e aceita argumentos. Um recurso é conteúdo somente leitura que o cliente busca por URI, mais próximo de ler um arquivo do que de chamar uma função.
Não por padrão. Cada requisição na etapa de troca é geralmente tratada como independente. Se um servidor precisar de memória entre chamadas, isso deve ser construído deliberadamente, geralmente com o apoio de um armazenamento externo, e não assumido do próprio protocolo.
Não. As quatro etapas são as mesmas para ambos. O que difere é como a etapa de conexão funciona mecanicamente, um pipe de subprocesso para stdio versus uma sessão de rede para HTTP/SSE.
A negociação é exatamente onde essa incompatibilidade aparece. O cliente e o servidor trocam informações de versão nesta etapa, e os SDKs geralmente lidam com o fallback para uma versão mutuamente suportada ou falham claramente se nenhuma existir.
Sim, especialmente via HTTP/SSE, onde várias sessões podem estar abertas simultaneamente. Cada sessão passa por suas próprias etapas de conexão e negociação independentemente, e o servidor deve manter seus estados separados.
Para servidores remotos, a autenticação ocorre na etapa de conexão ou antes dela, pois tudo após a negociação assume que a conexão já é confiável. Verificar credenciais dentro de manipuladores de ferramentas individuais é tarde demais no ciclo de vida para ser uma fronteira de segurança sólida.
Um cliente chama uma ferramenta get_weather com um argumento de cidade. O servidor roteia essa chamada para seu manipulador get_weather registrado, o manipulador executa e retorna dados estruturados, e o servidor envia esses dados de volta como a resposta, encerrando uma troca dentro da sessão maior.
O SDK gerencia a mecânica, mas entender as etapas ajuda você a diagnosticar por que uma ferramenta não está aparecendo, por que uma sessão se comporta inesperadamente sob clientes concorrentes, ou por que uma verificação de autenticação precisa estar onde está.
Sim. A negociação cobre todos os três tipos de capacidade juntos: ferramentas, recursos e prompts. Um recurso ou prompt que o servidor não declarou é tão invisível para o cliente quanto uma ferramenta não registrada.
Versões de Stack: Escrito contra a linha de modelos Claude atual em ~junho de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (o padrão), e Claude Haiku 4.5 - e os SDKs atuais do Model Context Protocol Python/TypeScript. Nomes de modelos, versões de SDK e a especificação MCP mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs e modelcontextprotocol.io antes de confiar neles.
Revisado por Chris St. John·Última atualização: 16 de jul. de 2026