MCP sans état et workflows d’agent avec état : playbook pour agents Android
Guide d’architecture sur MCP 2026-07-28, serveurs stateless, Tasks, MRTR, poignées d’état, approbations et workflows Android avec état côté agent téléphonique.
- MCP 2026-07-28 introduit un cœur de protocole sans état : les requêtes deviennent auto-descriptives, routables vers différentes instances et compatibles avec un modèle de déploiement plus flexible.
- Un protocole MCP sans état n’empêche pas un agent IA de conserver un état ; il déplace la responsabilité vers la couche applicative, le client, l’hôte agent ou des poignées explicites.
- Un agent téléphonique fiable doit posséder six états distincts : conversation, tâche, appareil, approbation, authentification et audit.
- FoneClaw montre pourquoi l’état côté hôte compte sur Android : assistant flottant, continuité de tâche sur le même téléphone, récupération de permissions et actions gouvernées restent visibles pour l’utilisateur.
Ce que MCP 2026-07-28 change vraiment
La spécification MCP 2026-07-28 marque un changement important : le cœur du protocole devient sans état. Dans la pratique, une requête MCP doit contenir les informations nécessaires pour être comprise et routée sans dépendre d’une session de transport implicite. Le serveur peut être redémarré, remplacé par une autre instance ou placé derrière un équilibreur de charge avec beaucoup moins de couplage au cycle de vie d’une connexion.
Le point clé pour un constructeur d’agent téléphonique est le suivant : MCP sans état et workflows d’agent avec état ne s’opposent pas. Le protocole peut devenir stateless, tandis que l’application reste stateful. L’état important d’une tâche Android ne vit pas naturellement dans une session réseau. Il appartient à l’hôte agent, au téléphone, au journal d’approbation, au magasin de tâches, à une poignée explicite ou à un service métier selon sa nature.
La proposition SEP-2575 sur MCP stateless explique le retrait du handshake d’initialisation obligatoire et le passage à des métadonnées par requête. La version 2026-07-28 ajoute aussi MRTR, le routage par en-têtes, des listes cacheables, un durcissement de l’autorisation et un cadre d’extensions. Pour les agents mobiles, cette évolution clarifie une responsabilité : le protocole transporte des appels d’outils ; l’agent téléphonique conserve l’intention, les permissions, les approbations et la reprise.
Cette séparation rejoint notre expérience FoneClaw. Quand un utilisateur demande une action Android, le téléphone a besoin d’un état durable : écran courant, permission manquante, approbation attendue, résultat vérifié. Pour approfondir la confiance dans la découverte des ressources et des outils, Agentic Resource Discovery : ai-catalog.json, registres et confiance pour agents mobiles développe la partie registre et source de capacité.
Comment fonctionne une requête MCP sans état
Dans un cycle stateless, chaque requête porte son identité de protocole, ses capacités utiles, ses métadonnées et les références nécessaires à la tâche. Une instance compatible peut traiter l’appel parce qu’elle n’a pas besoin de retrouver un état caché dans une connexion précédente. Cela facilite les déploiements serverless, les redémarrages, les répartitions de charge et les mises à jour progressives.
La découverte devient plus explicite. Le client ou l’hôte agent peut demander les outils, ressources ou capacités disponibles, puis mettre en cache certaines listes quand le protocole l’autorise. Les en-têtes aident au routage. Les métadonnées par requête remplacent les suppositions négociées dans une session implicite. Cette approche rend le transport plus prévisible, surtout quand plusieurs instances de serveur MCP existent derrière la même adresse.
Pour les opérations longues ou contextuelles, l’état passe par des références explicites. La proposition SEP-2567 sur les poignées d’état explicites décrit comment un serveur peut créer une référence qui sera transmise dans des appels ultérieurs. La poignée peut représenter un travail, un contexte calculé, une progression ou une ressource temporaire. Elle ne remplace ni l’autorisation utilisateur, ni le journal d’audit, ni l’état réel du téléphone.
Un workflow Android illustre bien ce point. Le serveur MCP peut recevoir une requête auto-descriptive ; l’hôte FoneClaw, lui, doit savoir si l’utilisateur a déjà approuvé l’envoi d’un SMS, si l’écran a changé, si la permission reste valable et si le résultat a été observé. Le protocole transporte le travail ; l’agent téléphonique possède le contexte de la tâche.
Les six états qu’un agent téléphonique doit posséder
En construisant FoneClaw, nous avons appris qu’un agent IA stateful sur téléphone doit séparer plusieurs registres. Les mélanger crée des erreurs : une conversation peut sembler claire alors que la permission manque ; une authentification peut être valide alors que l’action n’a pas été approuvée ; une poignée de tâche peut exister alors que l’écran Android a changé.
| Type d’état | Ce qu’il contient | Propriétaire naturel | Pourquoi il compte |
|---|---|---|---|
| Conversation | Demande, clarifications, choix de l’utilisateur, reformulations. | Hôte agent ou application de conversation. | Permet de comprendre l’intention sans confondre dialogue et autorisation. |
| Tâche | Objectif, étape courante, plan, poignée explicite, reprise possible. | Hôte agent ou magasin de tâches. | Permet de reprendre après interruption, redémarrage ou changement d’écran. |
| Appareil | Écran, app active, permission Android, réseau, double SIM, état du réglage. | Téléphone et couche d’exécution Android. | Doit être relu avant une action parce que le téléphone change rapidement. |
| Approbation | Action proposée, cible, conséquence, décision, expiration. | Hôte agent et journal d’approbation. | Relie la décision humaine à une action précise, pas à une session générale. |
| Authentification | Compte, jeton, droits de service, portée OAuth ou équivalent. | Client, coffre d’identifiants ou service d’identité. | Autorise l’accès technique, avec une portée distincte de l’approbation utilisateur. |
| Audit | Requête, outil appelé, idempotence, résultat, erreur, reprise. | Hôte agent ou journal de confiance. | Explique ce qui s’est passé et permet de diagnostiquer les effets externes. |
Cette carte évite de donner trop de responsabilités au serveur MCP. Un serveur peut calculer, exposer un outil ou porter une poignée explicite. L’agent téléphonique doit garder la cohérence entre intention, appareil, approbation et résultat. Pour approfondir l’identité, les permissions et la piste d’audit, Identité des agents IA : permissions, approbation par outil et piste d’audit donne le modèle de gouvernance associé.
Tâches MCP, MRTR, sollicitation de l’utilisateur et approbations
La spécification MCP 2026-07-28 introduit aussi des mécanismes qui aident les workflows longs. MRTR permet des interactions pendant un travail en cours. L’elicitation sert à demander une information à l’utilisateur ou au client lorsque la tâche a besoin d’une précision. Tasks apparaît comme une extension formelle pour représenter du travail qui dure au-delà d’un simple appel immédiat.
Ces éléments sont utiles pour un agent téléphonique. Une tâche Android peut attendre une permission, demander quel contact choisir, recevoir une correction, produire une progression ou être annulée. Une poignée Tasks peut représenter le travail côté protocole. Dans l’application, l’état de tâche doit aussi relier la demande initiale, l’écran Android, l’approbation, l’outil exécuté et la vérification du résultat.
L’approbation reste un état à part entière. Un handle de tâche indique où retrouver un travail ; il ne donne pas à lui seul le droit d’envoyer un message, de changer un réglage ou d’appeler un contact. L’authentification prouve une identité technique ou un accès de service ; l’approbation confirme qu’un utilisateur accepte une action précise dans un contexte donné. C’est une distinction essentielle pour les agents mobiles.
Dans nos conceptions FoneClaw, nous voulons que l’utilisateur voie la cible et l’effet avant les actions sensibles. Un serveur MCP peut être stateless et scalable ; le téléphone doit rester le lieu où la décision, la permission et la reprise sont compréhensibles.
Un workflow Android avec état au-dessus d’un MCP sans état
Prenons un workflow simple : « active Ne pas déranger pendant la réunion ». L’agent reçoit l’intention et crée un état de tâche local : objectif, durée, réglage visé, niveau de risque, permission nécessaire, état actuel à relire. Si un connecteur MCP intervient dans une architecture future, la requête envoyée au serveur peut être auto-descriptive : action demandée, métadonnées, identifiant de corrélation, clé d’idempotence, référence de tâche et capacités attendues.
Avant l’exécution, le téléphone relit l’état réel. Le mode Ne pas déranger est-il déjà actif ? La durée demandée est-elle claire ? L’utilisateur a-t-il approuvé l’effet ? La permission Android existe-t-elle ? Cette relecture évite qu’un plan ancien soit appliqué sur un appareil qui a changé. Dans FoneClaw, les capacités actuellement disponibles de continuité entre assistant flottant et Home, de récupération de permissions et d’actions rapides montrent pourquoi l’état côté hôte compte. La page Télécharger FoneClaw présente cette base actuelle.
Ensuite vient l’approbation visible. L’utilisateur voit l’action proposée : activer Ne pas déranger, pour telle durée, avec tel effet sur les notifications. Une fois l’action approuvée, l’exécution appelle l’outil gouverné correspondant. La clé d’idempotence aide à éviter une double application lors d’un retry. Après exécution, le téléphone vérifie le résultat : réglage actif, durée appliquée, erreur ou besoin de reprise.
Le même schéma vaut pour un SMS. L’agent garde le brouillon, le destinataire, l’application par défaut, l’approbation et l’état d’envoi. Si l’écran change ou qu’une permission manque, la tâche revient en récupération. Pour les appels, le choix entre protocole, connecteur et composeur natif mérite un traitement séparé ; Appels téléphoniques par agent IA : MCP ou composeur Android avec FoneClaw garde ce cas spécifique. Pour le contexte d’écran côté FoneClaw, Assistant IA flottant Android : comprendre et agir depuis l’écran actuel montre comment la continuité locale aide l’utilisateur à garder la tâche visible.
Faire évoluer les serveurs MCP sans perdre la fiabilité mobile
Un serveur MCP stateless apporte des bénéfices d’infrastructure : équilibrage de charge, redémarrage plus simple, scaling horizontal, instances éphémères, caches de découverte et déploiements progressifs. La version MCP Go SDK v1.7.0 illustre la prise en charge du protocole 2026-07-28 avec métadonnées par requête, découverte serveur et chemins de compatibilité pour versions antérieures.
La fiabilité d’une action téléphone demande une autre discipline : classer les retries. Relire une ressource est souvent récupérable. Préparer un brouillon peut être rejoué si l’idempotence est claire. Envoyer un SMS, modifier un réglage ou déclencher un appel demande déduplication, approbation et vérification. Chaque action à effet externe doit avoir un identifiant de corrélation, une clé d’idempotence et un résultat observé.
L’audit relie ces pièces. Quand un workflow échoue, nous voulons savoir quelle intention a lancé la tâche, quel outil a été appelé, quelle permission manquait, quelle approbation a été donnée, quel retry a eu lieu et quel résultat a été vu sur le téléphone. C’est cette trace qui permet une récupération propre plutôt qu’un recommencement flou.
Les workflows issus d’un enregistreur IA posent les mêmes questions : une note peut devenir une action, mais l’action doit rester confirmée et suivie. MCP pour enregistreur IA : des notes aux actions confirmées approfondit ce passage des captures aux tâches exécutables.
Frontières de sécurité et checklist de migration
La version MCP 2026-07-28 inclut un durcissement de l’autorisation, mais la sécurité d’un agent téléphonique ne se résume pas à l’authentification. Un accès technique peut autoriser un serveur à recevoir une requête. L’approbation utilisateur autorise une action précise. La permission Android donne accès à une capacité locale. L’audit raconte ensuite ce qui a été tenté, réussi, refusé ou récupéré.
Pour migrer vers un modèle MCP stateless, commencez par les requêtes : portent-elles toutes les métadonnées nécessaires ? Ensuite, identifiez les états implicites qui vivaient dans une session : capacités négociées, contexte utilisateur, progression, jetons temporaires, préférences, résultats partiels. Décidez où ils appartiennent : hôte agent, client, magasin de tâches, coffre d’identifiants, poignée explicite ou journal d’audit. Vérifiez aussi les chemins de compatibilité, car les clients et serveurs existants peuvent suivre des versions différentes du protocole.
Notre checklist de migration pour un connecteur de téléphone est directe :
- Décrire chaque outil avec ses capacités, permissions et effets externes.
- Faire porter aux requêtes les métadonnées nécessaires au routage.
- Utiliser des poignées explicites pour les travaux longs, avec expiration.
- Séparer authentification, approbation et permission Android.
- Ajouter une clé d’idempotence à chaque action à effet externe.
- Relire l’état de l’appareil avant l’exécution.
- Vérifier le résultat après l’action et journaliser l’issue.
- Prévoir annulation, reprise et compensation quand le contexte change.
Dans FoneClaw, nous utilisons notre produit actuel comme boussole d’architecture : un modèle configuré, des outils Android gouvernés, une action sensible visible et reviewable, un contexte déclenché par l’utilisateur et une récupération de permissions dans le flux. Les connecteurs MCP futurs devront respecter cette propriété d’état côté agent, même lorsque le transport reste sans état.