Vom Befehl zum Beleg: Die Entwicklung der Schnittstelle Northstar MCP
Diesen Beitrag anhören3 Min.
Gelesen von einer synthetischen Stimme, erzeugt aus dem Text dieses Beitrags.
Wird geladen …
Gelesen von einer synthetischen Stimme, erzeugt aus dem Text dieses Beitrags.Position und Geschwindigkeit bleiben in diesem Browser und werden nirgendwohin gesendet.
Die Aufnahme konnte nicht abgespielt werden. Audiodatei öffnen
Northstar MCP Model Context Protocol, ein offenes Protokoll, über das ein KI-Modell Werkzeuge aufruft und Daten aus anderer Software liest. v0.2.1 bleibt für dokumentierte Funktionen aktiv, nachdem frühere Testläufe Verbindungsfehler und Schutzlücken aufzeigten. Dem aktuellen Stand gingen ein abgelehnter Verbindungsaufbau in v0.1.0, ein funktional erfolgreicher Test mit offener Fehlerprüfung in v0.2.0 sowie ein erneuter Testlauf im Spiel voraus. Der dokumentierte Stand zum Abschluss des Piloten am 14. September 2026 um 12:29 UTC beschreibt eine begrenzte Fallstudie und keine allgemeine Sicherheits- oder Leistungszertifizierung. Die Entwicklung verdeutlicht, welche Belege erforderlich sind, bevor der Bauagent Veränderungen an einer bestehenden Stadt vornimmt.
Abnahmekriterien zwischen Agent und Spielwelt
Northstar MCP läuft als Modifikation im Spiel und stellt Werkzeuge bereit, mit denen der Bauagent Spielzustände abfragen und ausgewählte Aktionen auslösen kann. Im Rahmen des Projekts CS2 umfasst dies Abfragen zum Spielzustand, Kameraführung, Geschwindigkeit sowie Speichern, Laden und Zonierung.
Dabei unterscheidet das Protokoll zwischen der Annahme eines Auftrags und dessen tatsächlicher Ausführung in der Simulation. Ein angenommener Auftrag stellt noch keinen beobachteten Eingriff dar, eine zugewiesene Gewerbezone ist noch kein errichtetes Geschäft, und eine geschriebene Datei belegt zunächst nur den Speichervorgang. Erst das erneute Laden mit einem anschließenden Vergleich belegt, ob der untersuchte Zustand erhalten blieb. Aus diesen Anforderungen entstand eine mehrstufige Abnahmekette: die Identifikation der ausgelieferten Version, die Verbindungsprüfung mit dem tatsächlichen Client, die Ausführung eines begrenzten Auftrags, das unabhängige Rücklesen der Wirkung und die Überprüfung des Bestands nach dem Neuladen.
Drei Versionen und ihre Befunde
Die Entwicklung durchlief drei dokumentierte Schritte, die jeweils unterschiedliche Ergebnisse lieferten:
| Version | Dokumentierter Versuch | Ergebnis und damalige Konsequenz |
|---|---|---|
| v0.1.0 (13. September 2026) | Verbindungsaufbau mit dem tatsächlich eingesetzten Client | Initialisierung abgelehnt; kein Baupilot über diesen Client möglich. |
| v0.2.0 (14. September 2026) | Verbindung, Zustandslesen, Kamera, Tempo, Speichern und Zonierung | Mehrere Funktionen bestanden; offene Prüfung eines Fehler-Bypasses führte zum Rückwechsel. |
| v0.2.1 (14. September 2026) | Erneuter Verbindungstest, Schutzbefunde und begrenzter Spielversuch einschließlich Laden | Für konkret geprüfte Funktionen aktiv; weitere Werkzeugarten und Grenzfälle bleiben gesondert zu prüfen. |
Beim ersten Versuch mit v0.1.0 am 13. September 2026 antwortete der Server auf angepasste Diagnoseanfragen. Der tatsächliche Client scheiterte jedoch bei der Initialisierung mit dem Status HTTP 400, weil der Server einen zusätzlichen Header verlangte, den dieser Client nicht mitsandte. Es wurden keine Werkzeuge registriert, und der geplante Spielaufruf unterblieb.
In Version v0.2.0 am 14. September 2026 gelang der Verbindungsaufbau. Der Client erhielt einen Katalog von 36 Werkzeugen und las den Spielzustand aus. Die Steuerung von Kamera und Spielgeschwindigkeit funktionierte; auf die Einstellung der vierfachen Geschwindigkeit folgten eine Bestätigung und fortschreitende Simulationsframes, woraus jedoch kein vierfacher Rechendurchsatz abgeleitet werden kann. Bei einem Zonierungstest wurden 30 freie Zellen für Büros ausgewiesen, woraufhin zwei Bürogebäude entstanden und fertiggestellt wurden, während die kontrollierten Nachbargebäude unverändert blieben. Der Speichertest verweigerte das Überschreiben eines vorhandenen Namens ohne Freigabe, und die Dateihashes blieben unverändert. Dennoch erfolgte ein Rückwechsel auf den bisherigen Betrieb, da die Telemetrie den Zustand des Schalters ignoreErrors nicht auswies und der untersuchte Baupfad diesen Schalter vor Auftragsannahme und Ausführung nicht prüfte.
Schutzprüfungen und Bestandsabgleich in Version v0.2.1
Vor dem Piloten mit v0.2.1 wurden die Paketidentität und die tatsächlich im laufenden Spiel geladene Programmdatei abgeglichen. Die neue Version übermittelte den Schalterzustand ignoreErrors:false. Zwei Zusammenfassungen und eine Zustandsabfrage bestätigten die normalen Regeln für Geld, Gebäude und Karte. Der Quellenreview wies nach, dass Schutzprüfungen nun sowohl vor der Auftragsannahme als auch unmittelbar im Ausführungsschritt des Spiels greifen.
Im praktischen Test zonierte der Bauagent zwischen etwa 12:16 und 12:25 UTC 16 freie, straßennahe Zellen für niedriges Gewerbe bei eingeschaltetem Bestandsschutz. Die Schnittstelle meldete zunächst die Annahme und anschließend den Status observed. Eine gesonderte Rücklesung bestätigte die Zonierung auf allen 16 Zellen. Eine Schulplatzierung am Standort einer vorhandenen Schule wurde als Vorschau geprüft; die Schnittstelle erkannte die Überlappung und verweigerte die Platzierung in der Vorschau. Ein fehlerhafter Bauauftrag wurde nicht ausgeführt.
Beim anschließenden Ladeversuch blieben alle 16 zonierten Zellen erhalten. Zwei neue Geschäfte befanden sich im Bau, während vier bestehende Büros und die benachbarte Schule anhand von Gebäudetyp und Position wiedergefunden wurden, da sich die Objektkennungen beim Laden geändert hatten. Fertiggestellte Geschäfte, Nettoarbeitsplätze oder ein Bevölkerungswachstum wurden damit nicht nachgewiesen. Die Simulationsgeschwindigkeit wurde nach dem Laden manuell wieder auf die vierfache Stufe gesetzt, da ein automatisches Beibehalten nicht vorlag.
Der Umgang mit unvollständigen Daten
Die serverseitige Vorprüfung vor der Auftragsannahme lässt laut Review weiterhin einen unbekannten Schalterzustand zu. Die Betriebsregel des Bauagenten verlangt jedoch strengere Kriterien: Vor baulichen Eingriffen müssen konsistente Rückmeldungen und unmittelbar vor der Ausführung ein frischer Befund vorliegen, der bestätigt, dass der Fehler-Bypass ausgeschaltet ist. Unvollständige oder unbekannte Werte sperren bauliche Eingriffe.
Zudem enthalten Antworten auf Flächenabfragen Angaben zu Vollständigkeit und Abdeckung. Fehlt eine Kennzahl in einer Teilantwort, wird sie als unbekannt gewertet. Fehlende Beschäftigten- oder Einzugswerte wurden in den erfassten Daten nicht durch Nullen ersetzt, um unvollständige Daten nicht als Nullwerte zu interpretieren.
Aktueller Stand und offene Prüfpunkte
Northstar MCP v0.2.1 bleibt für die überprüften Abläufe aktiv. Die durchgeführten Tests decken jedoch nicht den gesamten Funktionsumfang ab: Elf Adaptertests wurden bestanden und reproduziert, während das absichtliche Einschalten des Bypasses und zeitkritische Wechsel nicht im Live-Betrieb geprüft wurden.
Der Katalog von 36 Werkzeugen stellt ein Angebot dar, das nicht mit dem geprüften Umfang gleichzusetzen ist. Es liegt keine Freigabe für Straßenbau, Errichtung einzelner Gebäude, Abriss, Budgetanpassungen, Richtlinien oder Bezirke vor. Ebenso wenig liegen Langzeit-, Last- oder Skalierungsnachweise vor. Der Bauagent kann die qualifizierten Schritte über die Schnittstelle ausführen und kontrollieren. Die langfristigen Auswirkungen auf Verkehr, Versorgung oder Stadtwachstum erfordern nachgelagerte Spielmessungen.