Sechs MCP-Tools und was die Adapter als Nächstes freischalten (jetzt 17)

Jedes Modell, das MCP spricht, kann die Runtime steuern — keine kundenspezifische Integration pro Anbieter. RakuAIs Sechs-Tool-Vertrag ist die Grenze, die eine Runtime mit deterministischer Autorität real macht, und der Wendepunkt, an dem sie zur Infrastruktur wird, auf der andere aufbauen.

Die Runtime spricht seit Ende März Model Context Protocol. Der ausgelieferte Commit ist 138b538b, „feat(mcp): reframe MCP server from game-agent control to world model runtime orchestration”. Die veränderte Rahmung in dieser Commit-Message ist der Kern dieses Beitrags, und der nächste Schritt dazu ist das, was ich festhalten will.

Wie MCP in der Runtime heute aussieht

Sechs Tools, in einem Python-Server unter src/mcp/raku_mcp_server.py, Transport über stdio, Namespace raku.*. Deny-by-Default-Berechtigungen, durchgesetzt pro Tool und pro Aufrufer. Jeder Aufruf wird in einem Audit-Log festgehalten.

Die sechs Tools:

1. load_world_model(adapter_name, config) registriert ein Weltmodell-Backend. Heute sind die Adapternamen Platzhalter: VideoPredictor-v2, NeuralRadianceField, PhysicsFoundation. Morgen werden es echte Adapter sein.
2. ingest_frame(adapter_name, frame_data, frame_index, timestamp) übergibt einen Frame aus einem generativen Modell an den Szenengraphen der Runtime.
3. get_scene_state(include_physics, include_transforms) ist die rein lesende Momentaufnahme der Welt. Sicher in jedem Modus.
4. set_render_target(target_type, config) konfiguriert, wohin die Welt gerendert wird: WebGL, VR-Headset, natives Fenster, Offscreen.
5. start_simulation(tick_rate, max_duration, realtime) startet die Simulationsschleife. Nur Sandbox und Entwicklung. Produktionsserver verweigern diesen Aufruf.
6. get_metrics() liefert eine Performance-Momentaufnahme. FPS, Frame-Zeit, Knotenanzahl, Adapterlast, Betriebszeit. Sicher in jedem Modus.

Rein lesende Tools funktionieren in jeder Umgebung. Mutierende Tools (load, ingest, set, start) funktionieren nur in Sandbox und Entwicklung. Die Produktionshaltung lautet: „Externe Agenten dürfen fragen, nicht anweisen.” Diese Haltung wird am Server durchgesetzt, nicht beim Aufrufer. Ein sich fehlverhaltender Partner kann ein Produktions-Weltmodell nicht versehentlich mutieren.

Warum genau diese sechs und nichts anderes

Die frühere Version des MCP-Servers, vor März, stellte Game-Agent-Tools bereit: move_npc, set_dialog, place_object, query_inventory. Das sind die falschen Tools für diese Grenze. Es sind Belange auf Anwendungsebene, nicht auf Engine-Ebene. Sie machen die Engine zu dem Ding, in das der Agent hineingreift. Die Engine soll aber das Ding sein, auf dem der Agent aufsetzt.

Die Neurahmung in PR #1311 tauschte die Tool-Oberfläche aus. Die neuen Tools operieren auf Weltmodell-Abstraktionen: ein Backend laden, einen Frame einspeisen, Zustand abfragen, Rendering konfigurieren, Simulation starten, Metriken lesen. Ein Agent, der einen NPC bewegen will, tut dies, indem er einen Frame durch den Weltmodell-Adapter schickt, nicht indem er move_npc auf der Engine aufruft. Die Engine bleibt die Autorität über Physik, Kollision, Punktestand, Multiplayer-Zustand. Das Weltmodell ist ein Beitragender, kein Steuernder.

Diese Unterscheidung ist es, die es der Engine erlaubt, agnostisch gegenüber dem verwendeten Weltmodell zu sein. Genie, Runway, Sora, bevor es abgeschaltet wurde, ein eigenes internes Modell, ein physikalisches Fundamentmodell, ein experimenteller Neural-Radiance-Field-Renderer. Alle sprechen dieselbe Sechs-Tool-Oberfläche. Keinem davon wird erlaubt, die Autorität der Engine darüber zu überschreiben, was in der Simulation tatsächlich geschieht.

Das ist es, was „Runtime mit deterministischer Autorität” in der Praxis bedeutet. Diesen Ausdruck verwenden wir häufig in Gesprächen mit Partnern. Die MCP-Oberfläche ist das, was ihn wahr macht.

Die Lücke zwischen heute und dem, was als Nächstes kommt

Die ehrliche Version davon, wo MCP steht: Der Server ist real, die Sicherheitsschicht ist gehärtet, die Schemas sind typisiert, das Audit-Log funktioniert, und die Adapter sind Stubs.

Das letzte Wort ist das Gewicht dieses Samstags. Die sechs Tools akzeptieren einen adapter_name-String. Die Stub-Adapter (VideoPredictor-v2, NeuralRadianceField, PhysicsFoundation) sind Platzhalter, die den Dispatch-Pfad belegen. Es gibt Gerüst-Dateien in src/environment/ für VeoEnvironmentAdapter und RunwayEnvironmentAdapter, die noch nicht an ein echtes Modell angebunden sind.

Der nächste Schritt ist ein Adapter, End-to-End, mit einem echten Partnermodell am anderen Ende. Der Kandidat, der in den Gesprächen seit der GDC immer wieder auftaucht, ist ein Video-Prädiktor (Runway oder ein kleineres offenes Modell), der Szenen-Frame-Daten über ingest_frame einspeist, während die Engine darunter Physik und Kollision übernimmt. Eine Demo, bei der die Bilder aus einem generativen Modell kommen und das Gameplay aus der Engine, und keine der beiden Seiten etwas von der anderen wissen muss, außer über die MCP-Grenze.

Wenn diese Demo funktioniert, ist jeder andere Adapter eine bekannte Form. Der schwierige Teil ist nicht die Integration. Der schwierige Teil ist der Vertrag. Der Vertrag sind die sechs Tools.

Was das für Partner bedeutet

Zwei konkrete Dinge, beide es wert, ausgesprochen zu werden.

Jeder Agent, der MCP spricht, kann die Runtime steuern. Ein Modell-Labor, das seine Generierung gegen eine echte Engine testen will, braucht keine kundenspezifische Integration. Es schreibt einen MCP-Client, ruft load_world_model mit seinem Backend auf, speist Frames mit ingest_frame ein, liest den Szenenzustand mit get_scene_state. Den Rest erledigt die Engine. Der Partner bekommt eine echte Evaluierungsoberfläche für sein Modell. Wir bekommen eine echte Demonstration, dass die Engine anbieterunabhängig ist.

Jeder Entwickler, der Tools auf der Runtime aufbaut, kann dieselbe Oberfläche nutzen. Der MCP-Server ist keine partnerexklusive API. Er ist die API. Ein Studio, das ein Autoring-Tool baut, ein Forscher, der Batch-Evaluierungen durchführt, ein Hardware-Partner, der einen neuen Sensor integriert – alle bekommen dieselben sechs Tools. Es gibt keine separate „interne” API, die sich hinter der öffentlichen versteckt. Es gibt die MCP-Oberfläche und die C-API, die das SDK verwendet, und das ist das gesamte öffentliche Gesicht der Runtime.

Die Härtungsarbeit, die noch aussteht

Drei Arbeitspakete, die ich festhalten will, damit sie erledigt werden:

Produktions-Deployment-Harness. Der MCP-Server wird heute in Tests instanziiert. Er braucht eine Service-Vorlage: Umgebungsvariablen-Konfiguration für Modus, Auth-Token und Rate-Limits, einen Health-Check-Endpunkt, sauberes Herunterfahren, Container-Paketierung. Standard-Ops-Hygiene. Nicht glamourös. Das, was aus einem funktionierenden Server einen einsatzfähigen macht.

Multi-Provider-Fallback. Wenn der primäre Adapter langsam oder nicht verfügbar ist, sollte der Server auf einen sekundären umleiten können. Das Strategiedokument spricht das schon eine Weile an. Die Umsetzung ist noch nicht gelandet. Die Form ist unkompliziert. Die Tests werden die eigentliche Arbeit sein.

Adapter-Bounty-Programm. Sobald ein Adapter End-to-End funktioniert und der Vertrag bewiesen ist, ist der richtige Schritt, den Adapter-Vertrag zu veröffentlichen und das Ökosystem einzuladen, weitere zu schreiben. Ein Genie-Adapter von jemandem, der Genie kennt. Ein Marble-Adapter von jemandem, der Marble kennt. Ein Custom-Modell-Adapter von einer Forschungsgruppe. Unsere Aufgabe hört auf, „jedes Modell integrieren” zu sein, und wird zu „den Vertrag veröffentlichen und die Implementierungen prüfen”.

Dieser letzte Schritt ist der, auf den ich mich am meisten freue. Es ist der Wendepunkt, an dem MCP aufhört, ein Tool zu sein, das wir für den eigenen Gebrauch gebaut haben, und anfängt, Infrastruktur zu sein, auf der andere Leute aufbauen.

Die Woche vor uns

In der Warteschlange, die ich diesen Samstagmorgen einreiche, steht der erste echte Adapter. Eng abgesteckt, schmales Ziel, funktionierende Demo bis Monatsende, wenn alles gut läuft. Wenn es nicht gut läuft, lernen wir, was wir am Vertrag falsch verstanden haben, solange Änderungen noch billig sind.

Wenn Sie in einem Modell-Labor arbeiten und eine Meinung dazu haben, wie MCP-artige Grenzen für Runtimes aussehen sollten, die mit generativen Modellen sprechen, ist das die richtige Woche, um sie zu teilen. Der Vertrag ist noch nicht festgeschrieben. Kommentare kosten jetzt weniger, als sie es in einem Quartal tun werden.

Sechs Tools, ausgeliefert, geprüft, schema-typisiert, Deny-by-Default. Als Nächstes die Adapter. Die Grenze ist real. Die Arbeit, die darauf aufbaut, ist das, was danach kommt.

Samstag in Bewegung.