MCP sampling descontinuado: sampling ou elicitation e o que usar agora

Se o seu servidor MCP chama sampling/createMessage, a especificação agora diz para você parar de construir em cima disso. Em 2026-07-28, o Model Context Protocol descontinuou o Sampling (SEP-2577), junto com Roots e Logging. O Elicitation, o recurso que a maioria das pessoas coloca no mesmo saco, não foi descontinuado. Ele foi reconstruído sobre um novo mecanismo de entrega. Este artigo separa o que está saindo do que continua, com as datas, nomes de campos e caminhos de substituição de que você precisa antes da próxima versão.

💡 Resumo rápido: O sampling está descontinuado, e a especificação diz para integrar diretamente com as APIs dos provedores de LLM. O elicitation está ativo e agora trafega por Multi Round-Trip Requests. Nada pode ser removido antes de uma revisão lançada em ou após 2027-07-28.

O que mudou em 2026-07-28

A revisão de 2026-07-28 reescreve a forma como clientes e servidores se comunicam, e a descontinuação do sampling é um item de um changelog extenso. Três mudanças importam aqui:

• Núcleo sem estado. O handshake initialize e o cabeçalho Mcp-Session-Id deixaram de existir. Cada requisição carrega sua versão do protocolo e as capacidades do cliente em _meta.
• Multi Round-Trip Requests (MRTR). Um servidor não pode mais enviar sampling/createMessage ou elicitation/create por uma conexão aberta. Ele devolve um resultado intermediário, e o cliente repete a chamada original com a resposta anexada.
• Um registro de descontinuação. Uma nova política de ciclo de vida define os estados Active, Deprecated e Removed, com uma janela mínima de doze meses antes de qualquer remoção.

A primeira mudança explica a segunda. Sem uma sessão persistente não há canal por onde enviar uma requisição, então as requisições do servidor para o cliente precisaram ser redesenhadas. O sampling foi redesenhado e descontinuado na mesma versão. O elicitation só foi redesenhado.

O que está descontinuado, num relance

O que "descontinuado" significa aqui

"Descontinuado" não é "removido". Durante a janela, o comportamento no nível do protocolo não muda, a negociação de capacidades continua funcionando e as implementações existentes seguem rodando. Novas implementações não devem adotar o recurso, e as existentes devem migrar. A remoção é uma decisão dos Core Maintainers tomada durante a preparação da versão, então pode acontecer depois da data mais cedo. A SEP também pede que as implementações emitam um aviso sempre que um recurso descontinuado for negociado, por isso os SDKs começaram a exibir avisos de descontinuação. Trate esses avisos como sua lista de tarefas.

⚠️ Armadilha: A página de descontinuação do SDK de Python diz que chamadas antigas no estilo de sessão, como ctx.session.create_message(), ainda funcionam em sessões negociadas em 2025-11-25 ou antes. Em uma conexão de 2026-07-28, elas emitem um aviso e depois geram erro, porque não sobrou nenhum canal de retorno para enviar.

Por que o sampling foi descontinuado

A SEP-2577 apresenta três motivos. Eles se somam.

Pesado demais para a maioria dos clientes

O sampling permite que um servidor peça ao modelo do cliente uma geração. Fazer isso direito exige aprovação humana, lógica de seleção de modelo, tratamento de segurança e, desde a SEP-1577, um loop de ferramentas. É muito para construir por um recurso que um servidor talvez nunca chame. A SEP aponta que poucos clientes suportam sampling, mesmo estando na especificação desde a revisão de novembro de 2024.

Uma grande superfície de ataque

A SEP considera o sampling o mais sensível à segurança dos três recursos descontinuados. Um servidor que consegue fazer o modelo do cliente executar seus prompts abre espaço para injeção de prompt e exfiltração de dados, então todo cliente precisa acertar as telas de revisão e os limites de taxa.

APIs diretas dão mais controle

Um servidor que precisa de um modelo pode chamar um provedor por conta própria. Ele escolhe o modelo, define os parâmetros e transmite a saída. O argumento antigo a favor do sampling era que os servidores não precisavam de credenciais próprias. A contrapartida agora é clara: você guarda as credenciais, paga a conta e decide o que acontece com os dados. Planeje para novas tentativas, limites de taxa e um modelo de reserva, porque essas coisas agora são sua operação, não a do cliente.

O elicitation não foi descontinuado

Confira a prova na própria especificação. O registro de recursos descontinuados lista Roots, Sampling, Logging, Dynamic Client Registration, os valores includeContext e o HTTP+SSE. O elicitation não está nele. A página do elicitation não traz aviso de descontinuação, e o changelog classifica o elicitation dentro do MRTR. Alguns textos agrupam todos os recursos de servidor para cliente, então confira o registro antes de repetir essa afirmação.

O elicitation perdeu dois detalhes: a notificação de finalização fora de banda e o campo elicitationId no modo URL. Um servidor que precisa associar uma nova tentativa a uma requisição anterior agora codifica seu próprio identificador dentro de requestState.

Modo formulário

O modo formulário coleta dados estruturados em banda, então o cliente vê a resposta. O requestedSchema é um objeto plano com apenas propriedades primitivas:

• strings, com formatos email, uri, date ou date-time
• números e inteiros
• booleanos
• enums de seleção única e de seleção múltipla

Objetos aninhados e arrays de objetos são intencionalmente não suportados. O usuário responde com uma de três ações: accept com conteúdo, decline ou cancel. Um servidor precisa tratar as três, inclusive oferecendo alternativas quando houver recusa.

⚠️ Servidores não devem pedir senhas, tokens de API, tokens de acesso ou dados de pagamento no modo formulário.

Modo URL

O modo URL envia o usuário para uma página fora de banda, e os dados nunca passam pelo cliente. É o caminho para entregas sensíveis e OAuth de terceiros. O cliente deve mostrar a URL completa, destacar o domínio, pedir consentimento e nunca fazer pré-carregamento da página. Uma resposta accept significa apenas que o usuário concordou em abri-la. Não significa que a interação terminou.

Minha leitura sobre por que ele sobreviveu: o sampling permite que um servidor pule um trabalho que ele mesmo poderia fazer chamando um provedor. O elicitation é a única via até a pessoa. Portões de confirmação antes de excluir, publicar ou pagar não têm uma API de provedor para recorrer, então remover o recurso deixaria os servidores no escuro.

Sampling ou elicitation, lado a lado

Os dois costumam ser chamados de substitutos, e não são. O sampling delega a geração de texto. O elicitation obtém a resposta de uma pessoa. Trocar uma chamada de sampling do tipo "resuma esta página" por um formulário seria a correção errada, já que o usuário nunca quis escrever esse resumo. O caminho inverso também está errado: usar o palpite de um modelo onde é preciso uma decisão humana.

Considere um servidor de imagens como caso prático. Antes de gastar uma geração, ele precisa de um estilo e de uma aprovação. As duas são escolhas humanas, então ele usa elicitation. Ele também quer um prompt mais rico do que o que o usuário digitou. Reescrever é geração de texto, que antes era uma chamada de sampling. Agora o servidor chama um provedor por conta própria, ou a descrição da ferramenta instrui o modelo hospedeiro a enviar um prompt mais completo desde o início.

Nesta revisão, os dois ainda passam pelo mesmo mecanismo, porque cada um aparece como uma entrada dentro de inputRequests. A diferença está em quem lê a entrada e no que a especificação diz sobre a vida útil dela.

Como funciona o novo ciclo de ida e volta

O fluxo tem quatro etapas. O cliente chama tools/call. O servidor devolve um InputRequiredResult com resultType: "input_required". O cliente reúne a resposta e repete a chamada original com inputResponses anexado. Então o servidor produz o resultado real. Como a nova tentativa carrega tudo o que o servidor precisa, qualquer instância atrás de um balanceador de carga consegue tratá-la.

Aqui está a resposta intermediária do servidor para uma ferramenta de imagens que precisa de uma proporção:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "aspect": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Which aspect ratio should the image use?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "ratio": { "type": "string", "enum": ["16:9", "1:1", "9:16"] }
            },
            "required": ["ratio"]
          }
        }
      }
    },
    "requestState": "<signed blob>"
  }
}

Copiar prompt

E a nova tentativa do cliente, com a resposta e o estado devolvido:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "generate_image",
    "arguments": { "prompt": "A foggy harbor at dawn" },
    "inputResponses": {
      "aspect": { "action": "accept", "content": { "ratio": "16:9" } }
    },
    "requestState": "<signed blob>"
  }
}

Copiar prompt

Os campos obrigatórios de _meta (versão do protocolo, informações do cliente, capacidades do cliente) foram omitidos aqui por brevidade. Observe que o id do JSON-RPC muda entre a requisição original e a nova tentativa, porque são requisições independentes.

Regras para clientes

• Devolva requestState exatamente como recebido. Nunca inspecione, interprete ou modifique.
• Se o resultado não tiver requestState, não envie um na nova tentativa.
• Use um novo id do JSON-RPC na nova tentativa.
• Se não houver inputRequests, o cliente pode tentar de novo imediatamente.
• Os campos afetam apenas a nova tentativa daquela requisição, nunca chamadas paralelas.

Regras para servidores

Trate requestState como entrada controlada por um atacante, porque ele passa pelo cliente. Quando ele influencia autorização, acesso a recursos ou lógica de negócio, proteja a integridade com um HMAC ou AEAD e rejeite tudo o que falhar na verificação. Coloque o usuário autenticado, uma validade curta e um identificador da requisição original dentro do payload protegido. Isso limita o replay, mas não torna um estado de uso único, então imponha que cada resgate seja de uso único no servidor.

Duas restrições a mais valem. Cada InputRequiredResult precisa de pelo menos um de inputRequests ou requestState, e um servidor não pode enviar um tipo de requisição que o cliente nunca declarou suportar. O MRTR funciona apenas em prompts/get, resources/read e tools/call.

O que usar no lugar do sampling

A resposta da especificação cabe em uma linha: integrar diretamente com as APIs dos provedores de LLM. Na prática, o substituto certo depende do motivo pelo qual você chamava o sampling.

Chame uma API de provedor diretamente

Quando você precisar de geração de texto de verdade, chame o provedor a partir do servidor. Compare os candidatos antes de colocar um no seu código. No PicassoIA você pode testar o Claude Sonnet 5, o GPT 5.6 Terra e o Gemini 3.5 Flash lado a lado e ver qual lida melhor com seus prompts na velocidade que você precisa. Depois, guarde a credencial como um segredo normal do servidor, defina um timeout e registre o uso de tokens.

Deixe o modelo hospedeiro raciocinar

Muitas chamadas de sampling nunca foram necessárias. O resultado de uma ferramenta já flui para o modelo que chamou a ferramenta. Devolva a página bruta, uma descrição clara e uma estrutura sensata, e o modelo hospedeiro faz o resumo sem uma ida e volta extra e sem credenciais extras. Um servidor de documentação que usava sampling para resumir um changelog longo pode devolver o changelog em seções e deixar o modelo que fez a chamada escolher o que importa. Esta é uma recomendação minha, não texto da especificação, mas elimina a maior parte das chamadas.

Peça ao humano pelas decisões

Quando a peça que falta é uma decisão, mude para elicitation. No SDK de Python, um texto mostra o padrão com uma escolha afirmativa:

CONFIRM = ["cancel", "confirm"]
result = await ctx.elicit("Delete 42 drafts?", response_type=CONFIRM)

Copiar prompt

O mesmo texto alerta que passar response_type=None envia um schema vazio, então uma aceitação automática parece idêntica a uma aprovação humana no protocolo. Dê ao usuário um valor real para escolher. Verifique a assinatura atual do seu SDK antes de copiar.

💡 Regra prática: se uma pessoa precisaria decidir, use elicitation. Se um modelo precisaria escrever, chame um provedor ou deixe o modelo hospedeiro fazer.

Uma checklist de migração para servidores

1. Encontre cada chamada. Procure por sampling/createMessage, create_message e quaisquer verificações de capacidade de sampling.
2. Classifique cada chamada pela finalidade. Geração de texto vai para uma API de provedor ou para o modelo hospedeiro. Decisões vão para elicitation. Contexto vai para argumentos de ferramentas ou URIs de recursos.
3. Remova os valores includeContext. Retire "thisServer" e "allServers". Omita o campo ou use "none".
4. Substitua Roots e Logging. Passe caminhos como parâmetros de ferramentas. Registre em stderr no stdio e use OpenTelemetry no restante.
5. Devolva InputRequiredResult. Troque as requisições iniciadas pelo servidor por resultados intermediários e um requestState assinado por você.
6. Teste numa conexão de 2026-07-28. Fique atento aos avisos de descontinuação do SDK e às chamadas antigas de sessão que geram erro.
7. Mantenha um caminho legado. Clientes em 2025-11-25 ou antes ainda usam o comportamento antigo durante a janela.

Cronograma para acompanhar

Três erros a evitar

1. Tratar descontinuado como removido. Sessões antigas ainda funcionam, mas conexões de 2026-07-28 rejeitam as chamadas antigas no estilo de sessão. Saiba quais versões você atende.
2. Usar um formulário para um texto que um modelo deveria escrever. O elicitation pede uma entrada a uma pessoa. Não é um jeito mais barato de redigir texto.
3. Pular a integridade do requestState. Estado sem assinatura é um convite aberto para adulterar a lógica do seu servidor.

Regras de revisão que continuam

A supervisão humana é a parte do sampling que continua valendo. Os clientes de elicitation devem mostrar qual servidor está pedindo, oferecer opções claras de recusar e cancelar, e deixar as pessoas revisarem as respostas do formulário antes de enviar. No modo URL, devem mostrar o domínio de destino e obter consentimento antes de abrir qualquer coisa. Os servidores devem vincular cada elicitation à identidade do usuário e verificar quem abre uma URL, o que bloqueia o padrão de phishing em que um invasor envia seu próprio link a uma vítima.

Crie suas próprias imagens com o Picasso IA

O trabalho com protocolos fica mais fácil quando você consegue ver o que está construindo. Se você estiver escrevendo um servidor MCP que gera imagens, o padrão de elicitation descrito acima se encaixa bem: peça uma proporção ou um estilo antes de gastar uma geração.

No PicassoIA você pode testar os modelos por trás desse tipo de ferramenta: PicassoIA Image para texto para imagem, PicassoIA Image Editor Pro para edições, e o GPT Image 2 quando quiser outro resultado. O PicassoIA também oferece uma API para desenvolvedores no estilo Replicate em https://api.picassoia.com/v1 e conexões MCP, então os mesmos geradores podem ficar por trás das suas próprias ferramentas. Confira os limites atuais na página da API antes de planejar em cima deles.

Abra o Picasso IA, escreva um prompt e gere sua primeira imagem. Depois, rode de novo com outra proporção e compare as duas. Esse pequeno ciclo é o mesmo padrão de pedir, responder e tentar de novo que este artigo descreveu, só que com pixels no final.