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.

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á.

Resumo

Ideia Central: Toda interação MCP passa pelas mesmas quatro etapas: conectar, negociar capacidades, trocar requisições e, eventualmente, desconectar.
Por que Importa: Um servidor que pula ou reordena uma etapa parecerá quebrado para o cliente, mesmo que cada manipulador de ferramenta individual esteja correto.
Conceitos Chave: conexão, negociação de capacidade, ferramentas, recursos, prompts, ciclo de requisição/resposta.
Quando Usar: Recorra a este modelo mental sempre que estiver depurando "o cliente não consegue ver minha ferramenta", projetando um novo manipulador ou decidindo o que pertence a uma ferramenta versus um recurso.
Limitações / Trade-offs: O ciclo de vida descreve a estrutura, não o desempenho. Um ciclo de requisição/resposta bem formado ainda pode ser lento, inseguro ou incorreto internamente.
Tópicos Relacionados: estruturação de um servidor mínimo, transporte stdio versus HTTP/SSE, autenticação de servidores remotos.

Fundamentos

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 é desmantelado

Nenhuma etapa pode ser pulada, e a etapa 3 não pode começar até que a etapa 2 termine com sucesso.

Mecânicas e Interações

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.

Considerações Avançadas e Aplicações

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.

Conceitos Errôneos Comuns

"Uma ferramenta existe assim que escrevo a função manipuladora." - O cliente só fica sabendo de uma ferramenta durante a negociação de capacidade, portanto, o manipulador também deve ser registrado na lista de ferramentas do servidor, não apenas implementado.
"Ferramentas, recursos e prompts são intercambiáveis." - São tipos de capacidade distintos com semânticas diferentes: ferramentas realizam ações e podem ter efeitos colaterais, recursos são conteúdo somente leitura, prompts são modelos reutilizáveis.
"O servidor se lembra do que aconteceu na última chamada de ferramenta." - A menos que o servidor persista explicitamente o estado fora da conexão, cada requisição deve ser tratada como independente; depender de memória implícita entre chamadas é uma fonte comum de bugs sutis.
"A negociação é uma formalidade que pode ser pulada em um servidor mínimo." - Mesmo um servidor mínimo construído com um SDK realiza a negociação automaticamente; pular ou configurar incorretamente isso é o que causa falhas do tipo "o cliente vê zero ferramentas".
"stdio e HTTP/SSE têm ciclos de vida fundamentalmente diferentes." - O ciclo de vida de quatro estágios é o mesmo para ambos, apenas o estágio de conexão difere em suas mecânicas.

FAQs

Quais são as quatro etapas do ciclo de vida da requisição MCP?

Conectar: cliente e servidor estabelecem um transporte.
Negociar: ambos os lados trocam capacidades suportadas e versão do protocolo.
Trocar: o cliente chama ferramentas, lê recursos ou busca prompts, e o servidor responde.
Desconectar: o transporte fecha e o estado da sessão é desmantelado.

Por que um cliente não pode chamar uma ferramenta antes que a negociação termine?

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.

Meu manipulador de ferramenta funciona quando o testo diretamente, mas o cliente diz que ele não existe. Por quê?

A função manipuladora provavelmente foi escrita, mas nunca registrada na lista de ferramentas do servidor.
O registro é o que faz uma ferramenta aparecer no manifesto de capacidade enviado durante a negociação.
Escrever a função sozinha não é suficiente; ela deve ser conectada às capacidades declaradas do servidor.

Qual é a diferença entre uma ferramenta e um recurso?

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.

O servidor precisa se lembrar de chamadas de ferramenta anteriores em uma sessã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.

O ciclo de vida é diferente para servidores stdio versus HTTP/SSE?

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.

O que acontece se um cliente e um servidor suportarem versões de protocolo diferentes?

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.

Um único servidor pode lidar com vários clientes ao mesmo tempo?

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.

Onde a autenticação se encaixa neste ciclo de vida?

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.

Qual é um exemplo prático de um ciclo de requisição completo?

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.

Por que este ciclo de vida é importante se eu estou apenas usando um SDK que o gerencia para mim?

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á.

Prompts e recursos também passam pela negociação de capacidade?

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.

Relacionados

Noções Básicas de Servidor MCP - estruture um servidor mínimo e veja o ciclo de vida em uma forma executável.
Comparação de Implantação MCP stdio vs HTTP/SSE - como a etapa de conexão difere por transporte.
Autenticando Servidores MCP Remotos - onde a autenticação se encaixa em relação às etapas de conexão e negociação.
Construindo um Servidor MCP com o SDK Python - veja o registro de ferramentas, recursos e prompts em código.

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.