Six outils MCP, et ce que les adaptateurs débloquent ensuite (désormais 17)
Tout modèle qui parle MCP peut piloter le runtime — sans intégration personnalisée par fournisseur. Le contrat à six outils de RakuAI est la frontière qui rend réel un runtime à autorité déterministe, et le point d'inflexion où il devient une infrastructure sur laquelle d'autres construisent.
Le runtime parle Model Context Protocol depuis fin mars. Le commit de livraison est 138b538b, « feat(mcp): reframe MCP server from game-agent control to world model runtime orchestration ». Le changement de cadrage dans ce message de commit est la substance de ce billet, et la prochaine étape à ce sujet est ce que je veux consigner.
À quoi ressemble MCP dans le runtime aujourd’hui
Six outils, dans un serveur Python à src/mcp/raku_mcp_server.py, transport via stdio, espace de noms raku.*. Permissions refus-par-défaut appliquées par outil et par appelant. Chaque appel enregistré dans un journal d’audit.
Les six outils :
load_world_model(adapter_name, config)enregistre un backend de modèle du monde. Aujourd’hui les noms d’adaptateurs sont des espaces réservés :VideoPredictor-v2,NeuralRadianceField,PhysicsFoundation. Demain ce seront de vrais adaptateurs.ingest_frame(adapter_name, frame_data, frame_index, timestamp)remet une image issue d’un modèle génératif dans le graphe de scène du runtime.get_scene_state(include_physics, include_transforms)est l’instantané en lecture seule du monde. Sûr dans tous les modes.set_render_target(target_type, config)configure où le monde se rend : WebGL, casque VR, fenêtre native, hors écran.start_simulation(tick_rate, max_duration, realtime)démarre la boucle de simulation. Bac à sable et développement uniquement. Les serveurs de production refusent cet appel.get_metrics()renvoie un instantané de performance. FPS, temps d’image, nombre de nœuds, charge de l’adaptateur, disponibilité. Sûr dans tous les modes.
Les outils en lecture seule fonctionnent dans tout environnement. Les outils de mutation (load, ingest, set, start) ne fonctionnent qu’en bac à sable et en développement. La posture de production est « les agents externes peuvent demander, pas ordonner ». Cette posture est appliquée au niveau du serveur, pas de l’appelant. Un partenaire mal élevé ne peut pas muter accidentellement un modèle du monde en production.
Pourquoi ces six et pas autre chose
La première version du serveur MCP, avant mars, exposait des outils d’agent de jeu : move_npc, set_dialog, place_object, query_inventory. Ce sont les mauvais outils pour cette frontière. Ce sont des préoccupations de niveau application, pas de niveau moteur. Ils font du moteur la chose dans laquelle l’agent va fouiller. Le moteur est censé être la chose sur laquelle l’agent tourne.
Le recadrage dans la PR #1311 a échangé la surface d’outils. Les nouveaux outils opèrent sur des abstractions de modèle du monde : charger un backend, pousser une image, interroger l’état, configurer le rendu, démarrer la simulation, lire les métriques. Un agent qui veut déplacer un PNJ le fait en poussant une image à travers l’adaptateur de modèle du monde, pas en appelant move_npc sur le moteur. Le moteur reste l’autorité sur la physique, les collisions, le score, l’état multijoueur. Le modèle du monde est un contributeur, pas un contrôleur.
Cette distinction est ce qui permet au moteur d’être agnostique quant au modèle du monde présent de l’autre côté. Genie, Runway, Sora avant sa fermeture, un modèle maison sur mesure, un modèle de fondation physique, un moteur de rendu expérimental à champ de radiance neuronal. Tous parlent la même surface à six outils. Aucun n’a le droit de passer outre l’autorité du moteur sur ce qui se passe réellement dans la simulation.
C’est ce que signifie « runtime à autorité déterministe » en pratique. Nous employons souvent cette expression dans les conversations avec les partenaires. La surface MCP est ce qui la rend vraie.
L’écart entre aujourd’hui et ce qui vient ensuite
La version honnête de l’état de MCP : le serveur est réel, la couche de sécurité est endurcie, les schémas sont typés, le journal d’audit fonctionne, et les adaptateurs sont des stubs.
Ce dernier mot est le poids de ce samedi. Les six outils acceptent une chaîne adapter_name. Les adaptateurs stub (VideoPredictor-v2, NeuralRadianceField, PhysicsFoundation) sont des espaces réservés qui prouvent le chemin de dispatch. Il y a des fichiers d’échafaudage dans src/environment/ pour VeoEnvironmentAdapter et RunwayEnvironmentAdapter qui ne sont pas encore câblés à un vrai modèle.
La prochaine étape est un adaptateur, de bout en bout, avec un vrai modèle partenaire à l’autre extrémité. Le candidat qui revient sans cesse dans les conversations issues de la GDC est un prédicteur vidéo (Runway, ou un modèle ouvert plus petit) alimentant des données d’image de scène via ingest_frame pendant que le moteur gère la physique et les collisions en dessous. Une démo où le visuel sort d’un modèle génératif et le gameplay sort du moteur, et où aucun des deux côtés n’a besoin de connaître l’autre sauf via la frontière MCP.
Si cette démo fonctionne, chaque autre adaptateur est une forme connue. La partie difficile n’est pas l’intégration. La partie difficile est le contrat. Le contrat, ce sont les six outils.
Ce que cela signifie pour les partenaires
Deux choses précises, toutes deux méritant d’être dites à voix haute.
Tout agent qui parle MCP peut piloter le runtime. Un laboratoire de modèles qui veut tester sa génération contre un vrai moteur n’a pas besoin d’une intégration personnalisée. Il écrit un client MCP, appelle load_world_model avec son backend, pousse des images avec ingest_frame, lit l’état de scène avec get_scene_state. Le moteur fait le reste. Le partenaire obtient une vraie surface d’évaluation pour son modèle. Nous obtenons une vraie démonstration que le moteur est agnostique au fournisseur.
Tout développeur construisant des outils par-dessus le runtime peut utiliser la même surface. Le serveur MCP n’est pas une API réservée aux partenaires. C’est l’API. Un studio construisant un outil d’création, un chercheur exécutant des évaluations par lots, un partenaire matériel intégrant un nouveau capteur, tous obtiennent les mêmes six outils. Il n’y a pas d’API « interne » séparée cachée derrière l’API publique. Il y a la surface MCP et il y a l’API C que le SDK utilise, et c’est là toute la façade publique du runtime.
L’endurcissement qui reste à faire
Trois éléments de travail que je veux consigner pour qu’ils se fassent :
Harnais de déploiement de production. Le serveur MCP est aujourd’hui instancié dans des tests. Il a besoin d’un modèle de service : configuration par variable d’environnement pour le mode, les jetons d’authentification et les limites de débit, un point de terminaison de contrôle de santé, un arrêt gracieux, un packaging conteneur. Hygiène opérationnelle standard. Peu glamour. La chose qui transforme un serveur fonctionnel en un serveur déployable.
Repli multi-fournisseur. Quand l’adaptateur principal est lent ou indisponible, le serveur devrait pouvoir router vers un secondaire. Le document de stratégie en parle depuis un moment. L’implémentation n’a pas encore atterri. La forme est simple. Les tests seront le vrai travail.
Programme de primes pour adaptateurs. Une fois qu’un adaptateur fonctionne de bout en bout et que le contrat est prouvé, le bon geste est de publier le contrat d’adaptateur et d’inviter l’écosystème à en écrire davantage. Un adaptateur Genie de quelqu’un qui connaît Genie. Un adaptateur Marble de quelqu’un qui connaît Marble. Un adaptateur de modèle sur mesure d’un groupe de recherche. Notre travail cesse d’être « intégrer chaque modèle » et devient « publier le contrat et relire les implémentations ».
Ce dernier geste est celui qui m’enthousiasme le plus. C’est le point d’inflexion où MCP cesse d’être un outil que nous avons construit pour notre propre usage et commence à devenir une infrastructure sur laquelle d’autres construisent.
La semaine à venir
La file d’attente que je dépose ce samedi matin contient le premier vrai adaptateur. Périmètre précis, cible étroite, démo fonctionnelle d’ici la fin du mois si tout se passe bien. Si cela ne se passe pas bien, nous apprenons ce que nous avions mal compris sur le contrat pendant qu’il est encore bon marché de le changer.
Si vous êtes dans un laboratoire de modèles et que vous avez un avis sur la forme que devraient prendre les frontières de style MCP pour des runtimes qui parlent à des modèles génératifs, c’est la bonne semaine pour le partager. Le contrat n’est pas encore verrouillé. Les commentaires coûtent moins cher maintenant qu’ils ne coûteront dans un trimestre.
Six outils, déployés, audités, typés par schéma, refus-par-défaut. Les adaptateurs ensuite. La frontière est réelle. Le travail qui tourne par-dessus est ce qui vient après.
Samedi en mouvement.
Pilotez un vrai moteur via un seul contrat MCP
Si votre modèle parle Model Context Protocol, il peut orchestrer un runtime spatial de production — agnostique au fournisseur, refus-par-défaut, chaque appel audité. Le contrat est ouvert aux commentaires pendant qu'il est encore bon marché à façonner.