O Modelo de Protocolo de Contexto (MCP) tem evoluído rapidamente.

Uma das mudanças mais interessantes na última especificação do MCP é a transição para um modelo de protocolo sem estado.

Recentemente, atualizei meu servidor de conversão de moeda MCP para funcionar com o novo comportamento sem estado e os novos pacotes SDK TypeScript divididos, particularmente @modelcontextprotocol/server.

Neste artigo, explicarei:

• O que as sessões MCP estavam fazendo
• O que "MCP sem estado" realmente significa
• Por que a mudança é importante para sistemas de produção
• Como o HTTP Streamable muda com a nova especificação
• Como migrei meu servidor de conversão de moeda MCP
• O que isso significa para a escalabilidade dos servidores MCP

O Que É MCP?

Se você é novo no MCP, o Modelo de Protocolo de Contexto é um padrão para conectar aplicações de IA a ferramentas, recursos e dados externos.

Em vez de construir integrações personalizadas entre cada aplicação de IA e cada serviço externo, o MCP fornece um protocolo comum.

Por exemplo, um assistente de IA pode usar um servidor MCP que expõe uma ferramenta como:

convert_currency

O modelo pode então solicitar:

Converter 100 USD para EUR.

O cliente MCP se comunica com o servidor MCP, que realiza a operação real e retorna o resultado.

Os servidores MCP podem expor várias primitivas, incluindo ferramentas, recursos e prompts.

No meu exemplo, o servidor é intencionalmente simples: ele expõe a funcionalidade de conversão de moeda.

O Antigo Modelo Mental: Sessões MCP

Antes das mudanças sem estado, o HTTP Streamable poderia manter uma sessão em nível de protocolo.

Conceitualmente, o fluxo parecia algo assim:

Cliente
   |
   | POST /mcp
   | inicializar
   v
Servidor MCP
   |
   | Mcp-Session-Id
   v
Cliente
   |
   | POST /mcp
   | Mcp-Session-Id: abc123
   v
Servidor MCP

O servidor cria uma sessão durante a inicialização.

Solicitações subsequentes contêm o identificador da sessão.

Isso significa que o servidor pode associar solicitações com a sessão que foi estabelecida anteriormente.

Isso não é necessariamente ruim.

O estado da sessão pode ser útil quando uma aplicação realmente precisa de estado de conversa ou de conexão.

Mas cria um problema arquitetônico quando queremos que os servidores MCP se comportem como serviços HTTP escaláveis horizontalmente comuns.

Por Que HTTP Com Estado Pode Se Tornar um Problema

Imagine implantar três instâncias de servidor MCP:

                    ┌─────────────┐
                    │ Balanceador  │
                    │ de Carga     │
                    └──────┬──────┘
                           |
             ┌─────────────┼─────────────┐
             |             |             |
             v             v             v
          Servidor A      Servidor B      Servidor C

Suponha que a solicitação de inicialização chegue ao Servidor A.

A sessão agora pertence ao Servidor A.

O que acontece quando a próxima solicitação chega ao Servidor B?

O Servidor B não necessariamente sabe nada sobre essa sessão.

Agora você precisa de mecanismos como:

• Sessões fixas
• Armazenamento de sessão compartilhado
• Replicação de sessão
• Coordenação distribuída

Isso adiciona complexidade à arquitetura de implantação.

A última direção do MCP remove essa dependência de sessão em nível de protocolo.

A equipe do MCP descreve o objetivo como permitir que as solicitações cheguem a qualquer instância do servidor sem exigir roteamento fixo ou um armazenamento de sessão de protocolo compartilhado. (Blog do Modelo de Protocolo de Contexto)

Entre MCP Sem Estado

A ideia chave é surpreendentemente simples:

Cada solicitação deve ser compreensível de forma independente.

Em vez de depender de uma sessão em nível de protocolo estabelecida anteriormente, a solicitação contém as informações necessárias para o servidor processá-la.

Conceitualmente:

Solicitação 1
   |
   v
Servidor A

Solicitação 2
   |
   v
Servidor C

Solicitação 3
   |
   v
Servidor B

Não há requisito de que todas as três solicitações cheguem à mesma instância.

Isso é uma adaptação muito mais natural para arquiteturas nativas da nuvem.

Sem Estado NÃO Significa Que Sua Aplicação Não Pode Ter Estado

Essa é uma distinção importante.

MCP sem estado não significa que toda a sua aplicação deve ser sem estado.

Suponha que você tenha uma ferramenta de carrinho de compras:

create_cart()

O servidor pode retornar:

{
  "cart_id": "cart_123"
}

A próxima chamada da ferramenta pode fornecer explicitamente:

{
  "cart_id": "cart_123",
  "product_id": "product_456"
}

A aplicação ainda tem estado.

Mas esse estado é representado explicitamente por dados da aplicação em vez de estar oculto dentro de uma sessão de protocolo MCP.

A equipe do MCP recomenda explicitamente esse tipo de estado em nível de aplicação quando o estado precisa persistir entre chamadas. (Blog do Modelo de Protocolo de Contexto)

Essa é uma melhoria arquitetônica sutil, mas importante.

O Que Mudou no HTTP Streamable?

O HTTP Streamable é o transporte importante para servidores MCP remotos.

A especificação de 2026-07-28 mudou seu comportamento significativamente.

O novo modelo remove:

• Sessões em nível de protocolo
• O Mcp-Session-Id
• O endpoint de stream GET autônomo

Em vez disso, o servidor expõe um único endpoint MCP que aceita solicitações POST.

Cada solicitação JSON-RPC é enviada como sua própria solicitação HTTP.

O servidor pode retornar tanto:

application/json

ou um stream SSE associado a essa solicitação.

(GitHub)

Assim, o modelo mental se torna:

POST /mcp
      |
      v
+----------------+
| Servidor MCP   |
|                |
| Processar solicitação|
|                |
| Retornar r