MCP stateless e fluxos stateful: como desenhar agentes Android confiáveis
Entenda o MCP 2026-07-28 sem estado, por que agentes de telefone ainda precisam manter estado de tarefa e como projetar aprovações, retries e recuperação no Android.
- O MCP 2026-07-28 torna o núcleo do protocolo stateless: cada requisição deve carregar metadados suficientes para roteamento, descoberta e execução por qualquer instância compatível.
- Stateless no transporte não elimina estado de aplicação; um agente de telefone precisa manter conversa, tarefa, dispositivo, aprovação, autenticação e auditoria em lugares explícitos.
- MCP Tasks, MRTR, elicitation e handles ajudam a organizar trabalho longo e entrada do usuário, mas aprovação, identidade, permissão e estado Android continuam responsabilidades do host do agente.
- Na FoneClaw, usamos a experiência atual de continuidade no mesmo telefone, recuperação de permissões e ações governadas como referência prática para desenhar fluxos Android recuperáveis sobre conectores escaláveis.
O que mudou no MCP 2026-07-28
A atualização do MCP em 28 de julho de 2026 trouxe uma resposta importante para quem constrói agentes: o núcleo do protocolo passa a favorecer um modelo stateless. A visão geral da especificação MCP 2026-07-28 apresenta requisições autodescritivas, roteamento por cabeçalhos, listas cacheáveis, MRTR, endurecimento de autorização, framework de extensões e Tasks como extensão formal.
Em linguagem de produto, stateless significa que o transporte deixa de depender de uma sessão implícita longa entre cliente e servidor. Uma requisição deve carregar metadados suficientes para que uma instância compatível consiga processá-la, mesmo em ambientes com balanceamento, reinício ou infraestrutura serverless. O SEP-2575, Make MCP Stateless, explica essa mudança ao remover a obrigatoriedade de handshake de inicialização e deslocar pressupostos de sessão para metadados por requisição.
Para agentes de telefone, essa mudança resolve um problema de infraestrutura, mas deixa clara uma responsabilidade de aplicação. O estado da tarefa continua existindo: qual ação o usuário pediu, que permissão foi concedida, que tela Android está ativa, que aprovação está pendente e qual resultado já foi observado. A FoneClaw nos ensinou isso no produto: transporte escalável ajuda, mas a confiança do usuário nasce no host que mantém estado, aprovação, recuperação e auditoria. Para aprofundar descoberta confiável de recursos, Agentic Resource Discovery: catálogo confiável sem confundir descoberta com autorização separa bem descoberta, confiança e permissão.
Como funciona o ciclo stateless de uma requisição MCP
No ciclo stateless, uma requisição MCP precisa chegar pronta para roteamento. Em vez de depender de uma negociação prévia escondida na sessão de transporte, ela carrega versão, capacidades, identidade aplicável, contexto de ferramenta e referências explícitas ao trabalho em andamento. Isso permite que várias instâncias de servidor atendam chamadas sem ficar presas ao mesmo processo ou conexão.
Descoberta também muda de papel. O cliente pode obter listas cacheáveis de ferramentas, recursos e capacidades, depois chamar o servidor com metadados que indicam o que espera. Roteamento por cabeçalho ajuda gateways e balanceadores a encaminhar a requisição. Quando há estado de servidor necessário, a proposta de MCP sem sessão por handles explícitos de estado mostra um padrão útil: o servidor emite um handle e chamadas futuras passam esse handle de forma explícita.
Esse handle melhora clareza, mas não substitui o estado do produto. Em um telefone, o handle pode apontar para um trabalho longo em um conector, enquanto o host do agente mantém o objetivo do usuário, a tela atual, a aprovação, o idempotency key, a autorização e o histórico. A aplicação fica stateful de propósito; o protocolo deixa de exigir estado implícito no transporte.
A leitura correta para arquitetura é: qualquer instância compatível pode receber a chamada, mas nem toda função vira uma única chamada. Um fluxo Android pode usar várias requisições MCP, chamadas nativas, aprovações locais e verificações de tela. O segredo é passar referências explícitas e manter o estado de tarefa no lugar certo.
Seis estados que um agente de telefone precisa manter
Quando construímos a FoneClaw, aprendemos que a confiabilidade de um agente de telefone depende de livros de estado separados. Misturar tudo em uma sessão de protocolo torna o sistema frágil. Um agente de IA com estado precisa saber o que é conversa, o que é tarefa, o que é dispositivo, o que é aprovação, o que é autenticação e o que é auditoria.
| Estado | Dono natural | O que precisa guardar | Como passa para ferramentas |
|---|---|---|---|
| Conversa | Host do agente | Pedido, correções, preferências temporárias e contexto verbal | Resumo escopado para a chamada necessária |
| Tarefa | Host do agente | Objetivo, etapa atual, plano, dependências, status e idempotency key | Task handle ou identificador de etapa |
| Dispositivo | Telefone | Tela atual, app ativo, permissões, conectividade, SIM, bloqueio e estado do Android | Leitura fresca antes de executar |
| Aprovação | Host e usuário | Alvo, consequência, escopo, validade e decisão | Registro explícito ligado à ação |
| Autenticação | Sistema ou serviço autorizado | Conta, token, papel, expiração e escopo técnico | Credencial limitada ao serviço |
| Auditoria | Host do agente | Quem pediu, qual ferramenta agiu, resultado, falha e recuperação | Correlation id e registro de resultado |
Aprovação e autenticação merecem separação. Um token pode permitir chamar um serviço, enquanto a aprovação do usuário autoriza aquela ação naquela tarefa. Do mesmo modo, um handle de MCP pode continuar um trabalho, mas o host do agente ainda precisa saber se a ação externa foi aprovada e se o estado do telefone continua válido.
O estado do dispositivo exige releitura. Uma tela Android pode mudar, uma permissão pode expirar, a rede pode cair, o usuário pode trocar de app e um pop-up pode cobrir o botão. Por isso, o agente deve passar referências para ferramentas e revalidar o Android antes de ações com consequência. Para aprofundar identidade, permissão e trilha de auditoria no celular, Identidade de agentes de IA: permissões, aprovação por ferramenta e auditoria no Android desenvolve esse modelo.
MCP Tasks, MRTR, elicitation e aprovações
MCP 2026-07-28 também formaliza peças que ajudam em trabalho longo. Tasks entra como extensão para representar tarefas assíncronas ou duráveis. MRTR permite interações em que o modelo solicita ferramentas durante o raciocínio. Elicitation organiza momentos em que o sistema precisa obter informação do usuário. Essas peças combinam bem com agentes de telefone, desde que o estado de aplicação continue explícito.
Pense em uma tarefa de mensagem: o modelo precisa perguntar qual Ana, preparar rascunho, esperar aprovação e só então executar o envio suportado. Tasks pode representar o trabalho em andamento, e MRTR pode solicitar a ferramenta adequada. A aprovação, porém, precisa estar vinculada ao destinatário, ao texto, ao app, ao momento e à consequência. Um task handle ajuda a retomar; a decisão do usuário autoriza a etapa.
Cancelamento e expiração também fazem parte do desenho. Se a tarefa aguardou muito, o telefone mudou ou a permissão foi removida, o host deve pedir nova verificação. Essa é a diferença entre estado útil e memória perigosa. O agente precisa preservar intenção suficiente para retomar, mas revalidar o que pode ter mudado antes de agir.
Na prática, usamos essa leitura como referência arquitetural: transporte stateless, Tasks como extensão, aprovação como estado de produto e Android como ambiente que precisa ser verificado no momento da ação.
Um fluxo Android stateful sobre MCP stateless
Imagine um fluxo de Não Perturbe. O usuário diz: ative Não Perturbe por 45 minutos porque vou entrar em reunião. O host do agente cria uma tarefa com objetivo, duração, estado inicial, idempotency key e política de aprovação. A requisição a um conector pode ser stateless: ela carrega metadados, versão, ferramenta desejada e referência explícita à etapa. O conector não precisa conhecer a conversa inteira.
Antes de executar, o host relê o estado do telefone. O Android permite esse ajuste? O usuário concedeu a permissão? A duração está clara? A ação afeta notificações de modo sensível? A aprovação aparece com alvo e consequência: ativar Não Perturbe por 45 minutos. Depois da aprovação, a ferramenta executa a mudança suportada. Em seguida, o host verifica se o estado final corresponde ao pedido.
Se a permissão estiver ausente, a recuperação vira parte da tarefa. O agente mostra por que o acesso é necessário, conduz o usuário para a tela adequada e retoma quando o estado muda. Se a requisição ao conector falha por timeout, o idempotency key ajuda a classificar retry. Se o estado já foi alterado, a verificação evita aplicar a mesma ação duas vezes.
O mesmo padrão funciona para SMS, discador, navegação e ajustes selecionados. A base atual da FoneClaw reforça essa ideia com assistente flutuante, continuidade de tarefa no mesmo telefone, recuperação de permissões e ações rápidas; a página de download da FoneClaw apresenta as capacidades atualmente disponíveis. A página de recursos da FoneClaw mostra como os fluxos governados e 100+ built-in tools se encaixam nessa experiência.
Para entender a continuidade visual do host no Android, Assistente de IA flutuante no Android: use a tela atual com controle explica como o contexto de tela atual e a continuidade no mesmo telefone ajudam o usuário a revisar e recuperar uma tarefa. Para chamadas, Chamadas telefônicas com agentes de IA: MCP, Dial e discador Android com FoneClaw separa bem conector, intenção e ação nativa do discador.
Escalar servidores MCP sem perder confiabilidade
O benefício operacional do MCP stateless é forte: instâncias podem reiniciar, balanceadores podem distribuir chamadas e ambientes serverless podem processar requisições sem uma sessão de transporte durável. O MCP Go SDK v1.7.0 documenta suporte ao ciclo do protocolo 2026-07-28, metadados por requisição, descoberta de servidores e caminhos de compatibilidade com versões anteriores.
Para fluxos de telefone, escala precisa vir acompanhada de confiabilidade. Retry de leitura é diferente de retry de ação externa. Consultar uma lista de ferramentas pode ser repetido com baixo risco; enviar SMS, alterar configuração ou iniciar chamada exige deduplicação, idempotência e verificação. O host do agente deve registrar correlation id, idempotency key, ferramenta chamada, entrada, aprovação usada, estado antes, estado depois e resultado observado.
Falhas também precisam de classificação. Timeout antes da execução, timeout depois da execução, permissão ausente, estado de tela incompatível e conector indisponível pedem respostas diferentes. Às vezes o retry é seguro. Às vezes a próxima ação é verificar estado. Em outros casos, o usuário precisa assumir a tela. A página MCP para gravadores com IA: de notas a ações confirmadas mostra o mesmo raciocínio em fluxos que começam com captura e terminam em ação confirmada.
Limites de segurança e checklist de migração
Segurança em MCP stateless começa com separação de responsabilidades. Autenticação prova que uma chamada pode acessar um serviço dentro de um escopo técnico. Aprovação prova que o usuário autorizou uma ação específica dentro de uma tarefa. Um task handle referencia continuidade; a autorização e a aprovação precisam estar ligadas ao usuário, ao serviço, ao dispositivo, ao momento e à consequência.
A migração para MCP 2026-07-28 deve ser gradual. O SDK Go mostra caminhos de compatibilidade com versões anteriores, e implantações reais terão clientes e servidores em ritmos diferentes. Para um agente de telefone, a transição segura começa por endpoints de leitura, passa por ferramentas idempotentes e só depois chega a ações com efeito externo. Cada etapa precisa de observabilidade, correlação e verificação de resultado.
Nosso checklist de arquitetura para conectores de telefone é direto:
- Declare versão MCP, capacidades e extensões aceitas por requisição.
- Mantenha conversa, tarefa, dispositivo, aprovação, autenticação e auditoria em livros de estado separados.
- Use handles explícitos para continuar trabalho, com expiração e escopo.
- Gere idempotency key para ações externas e registre correlação de ponta a ponta.
- Releia estado Android antes de executar qualquer etapa sensível.
- Vincule aprovação ao alvo, consequência, ferramenta e validade.
- Classifique falhas antes de retry e confirme resultado depois de executar.
- Planeje compatibilidade com clientes legados e migração por capacidade.
É assim que lemos MCP stateless e fluxos de agente stateful na FoneClaw: o protocolo fica mais simples de escalar, e o produto fica responsável por manter estado útil, visível e recuperável. Essa combinação é o que torna um agente de telefone confiável no Android real.