MCP Não Está Morto: O Que as Últimas Atualizações do MCP Significam para Servidores de Memória

TL;DR

• As versões de abril do Claude Code aumentaram a saída de MCP por ferramenta para 500.000 caracteres, adicionaram conexões de servidor simultâneas e lançaram Pesquisa de Ferramentas + carregamento preguiçoso.
• Para a maioria dos servidores MCP (Slack, GitHub, sistema de arquivos), isso é um aumento na qualidade de vida.
• Para servidores de memória, as quatro mudanças se acumulam. Elas mudam o problema de design de "qual é a menor resposta útil que podemos encaixar?" para "qual é a carga mais rica que o modelo realmente usará?"

Se você executou um servidor MCP que expõe memória ao Claude, você sentiu a pressão.

As ferramentas competem pelo orçamento de tokens. O modelo escolhe um ou dois itens de memória por vez, e então fica sem espaço. Você pode retornar mais do seu servidor, mas o prompt só suporta tanto antes que o assistente comece a ignorar coisas. Ou você envia menos contexto, ou você envia menos contexto útil. Não havia uma terceira opção.

Abril mudou essa matemática. Quatro atualizações chegaram próximas umas das outras. Sozinhas, nenhuma delas é o tipo de nota de lançamento que você retweetaria. Empilhadas, elas remodelam o que um servidor de memória pode realmente fazer em uma sessão — e a maioria dos textos que vi trata elas como vitórias genéricas para desenvolvedores, em vez do tipo específico de vitória que são para a memória.

Aqui está o que mudou, o que cada uma significa para um servidor de memória em particular, e as alterações de configuração que valem a pena fazer esta semana.

O que foi lançado

1. Limite de saída de MCP por ferramenta aumentado para 500.000 caracteres. Este é o destaque. O limite antigo forçou os servidores de memória a truncar agressivamente.
2. Conexões simultâneas de servidor MCP. Vários servidores podem ser consultados em paralelo dentro de uma única vez. Anteriormente, você tinha que enfileirar.
3. Pesquisa de Ferramentas MCP. Claude pesquisa entre as ferramentas registradas em vez de carregar cada descrição de ferramenta no prompt do sistema.
4. Carregamento preguiçoso. Esquemas de ferramentas são carregados quando são necessários, não no início da sessão.

Duas dessas mudanças alteram o que seu servidor pode entregar. Duas liberam o orçamento do prompt que você estava pagando para ter seu servidor registrado. Elas se acumulam.

O que isso significa para um servidor de memória, concretamente

Os servidores de memória têm uma forma estranha dentro do MCP. A maioria dos servidores tem tetos naturais sobre o que devem retornar — um conector Slack devolve mensagens recentes, um MCP do GitHub busca um arquivo, um MCP de sistema de arquivos lista um diretório. A memória não tem um teto óbvio. A resposta mais útil é frequentemente "tudo relevante para a pergunta", e em 2025 isso significava "tudo que conseguimos encaixar no orçamento de truncamento."

500.000 caracteres por chamada de ferramenta muda esse teto.

Agora você pode retornar:

• Resumos completos de conversas com timestamps e referências, não resumos de uma linha
• Trechos de documentos originais com proveniência ao lado do fato extraído
• Síntese de múltiplas fontes em uma única chamada em vez de forçar o agente a fazer quatro
• Memórias de habilidades ou regras com exemplos incluídos, não apenas o nome da regra

A troca se inverteu. A pergunta não é mais "qual é o mínimo que podemos retornar que ainda responde à pergunta?" agora. É "qual é a carga útil máxima antes que o modelo comece a ignorar a estrutura?" Esse é um problema de otimização muito melhor para se ter.

A mudança de conexão simultânea é mais importante para configurações de pilha cruzada. Se você executa um servidor de memória ao lado de um MCP do GitHub, um MCP de sistema de arquivos e um MCP de busca na web, a recuperação da memória agora se sobrepõe a tudo o mais em vez de bloquear nisso. O tempo total de espera diminui, mas o efeito mais importante é que o modelo não está esperando pela memória antes de começar a raciocinar.

Uma configuração do Claude Desktop que opta pelo novo comportamento

Se sua configuração se parece com o padrão de 2025, você está deixando o novo espaço em branco no chão. Aqui está a forma que aproveita isso:

{
  "mcpServers": {
    "memory": {
      "url": "https://<seu-endpoint-de-memória>",
      "headers": {
        "Authorization": "Bearer <SUA_CHAVE_API_SECRETA>"
      }
    },
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/caminho/para/projeto"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

Alguns detalhes específicos que vale a pena saber:

• A ordem importa menos do que antes. Com conexões simultâneas, Claude não está percorrendo seus servidores de cima para baixo. A configuração é um registro agora, não uma lista de prioridades.
• Se seu servidor de memória retorna grandes cargas, estruture-as. Um blob de texto não estruturado de 400K caracteres desperdiça o novo teto. Seções com cabeçalhos, atribuição de fontes e timestamps sobrevivem muito melhor à passagem de compressão do modelo do que paredes de prosa.
• Não exponha todas as ferramentas. O carregamento preguiçoso ajuda, mas você ainda paga o custo de listagem quando a Pesquisa de Ferramentas inventaria seu servidor. De cinco a dez ferramentas bem nomeadas por servidor é o número certo. Vinte é demais.

Estrutura supera volume

A coisa que eu destacaria, porque não é óbvio, é que "use o novo espaço" não significa "encha-o até a borda." O orçamento de atenção ainda é orçamento de atenção. O modelo pode tecnicamente ler uma carga de 500K; se ele usa alguma dela depende de se a estrutura torna as partes úteis encontráveis.

Retornos que funcionam:

# Recordar: "o que eu trabalhei esta semana"

## Resumo
- Passei três dos cinco dias no Projeto X (migração de autenticação)
- Mantive uma decisão pendente sobre a escolha do esquema do Projeto Y

## Fontes
- 2026-05-20  Slack #projeto-x  → "shi