From Command to Evidence: The Development of Northstar MCP
Listen to this post3 min
Read by a synthetic voice, generated from the text of this post.
Loading…
Read by a synthetic voice, generated from the text of this post.Position and speed stay in this browser and are sent nowhere.
The recording could not be played. Open the audio file
Northstar MCP Model Context Protocol, an open protocol through which an AI model calls tools and reads data from other software. v0.2.1 remains active for documented functions following pilot runs that revealed connection errors and protection gaps. The current status was preceded by a rejected connection setup in v0.1.0, a functionally successful pilot with an unverified error bypass in v0.2.0, and an in-game retest. Completed at 12:29 UTC on 14 September 2026, the documented pilot describes a case study with limited tests rather than a general safety certification or performance evaluation. The development process demonstrates the evidence required before the building agent can make changes to an existing city.
Verification Steps Between Agent and Game World
Northstar MCP runs as an in-game modification, providing tools that allow the building agent to read game states and request specific actions. Within the CS2 project, the pilot examined functions including state queries, camera controls, simulation speed, saving, loading, and zoning.
Throughout testing, the protocols distinguished between an accepted request and an observed intervention. An accepted order does not constitute an observed modification, an assigned commercial zone is not a finished business, and a written file only confirms the saving process. Only reloading and comparing the city state proves whether the investigated properties were retained. This distinction led to a multi-step acceptance chain: identifying the delivered version, verifying the connection with the operational client, executing a limited order, independently reading back its impact, and inspecting the relevant urban stock after loading.
Findings Across Three Interface Versions
The development involved three documented iterations, each yielding distinct results:
| Version | Documented Test | Result and Subsequent Action |
|---|---|---|
| v0.1.0 (13 September 2026) | Connection setup with the operational client | Initialization rejected; no building pilot possible through this client. |
| v0.2.0 (14 September 2026) | Connection, state reading, camera, speed, saving, and zoning | Multiple functions passed; an unverified error bypass caused a reversion to previous operations. |
| v0.2.1 (14 September 2026) | Connection retest, protection findings, and limited in-game test including loading | Active for verified functions; further tool types and edge cases require separate evaluation. |
During the initial test of v0.1.0 on 13 September 2026, the server responded to specialized diagnostic queries. However, the operational client failed during initialization with an HTTP 400 response because the server required an additional header that the client did not send. No tools were registered in the client, and the planned game call was not executed.
Version v0.2.0 passed the client connection setup on 14 September 2026. The client received a catalog of 36 tools and read the game state. Camera controls and game speed were tested; selecting quadruple speed produced corresponding feedback and advancing simulation frames, though this does not indicate a measured fourfold computational throughput. In a building test, 30 previously empty cells were designated as office zones, resulting in two completed office buildings while monitored neighboring structures remained intact. A save test confirmed that the interface refused an existing filename without overwrite permission, leaving file hashes unchanged. However, a source review identified that telemetry lacked the state of the ignoreErrors switch, and the building path did not check this switch before accepting or executing orders. This unverified bypass led to a reversion to previous operations.
Protection Checks and Post-Load Verification in v0.2.1
Before running the v0.2.1 pilot, package identity and the binary loaded by the active game were matched. The updated version reported ignoreErrors:false. Two summaries and one state query confirmed the standard rules governing finances, buildings, and maps. The source review verified that protection checks were implemented both prior to order acceptance and directly within the game execution step.
During the live pilot, conducted between approximately 12:16 and 12:25 UTC, the building agent zoned 16 empty roadside cells for low-density commercial use with building preservation enabled. The interface reported order acceptance followed by the status observed. A separate read-back verified the commercial zoning across all 16 cells. A preview test for placing a school over an existing school reported the structural overlap and prevented placement in the preview; an intentional invalid placement was not executed.
A subsequent load test confirmed that all 16 zoned cells persisted after reloading. Two new commercial structures were under construction, and four existing offices alongside the neighboring school were matched by building type and location, as internal object identifiers changed upon loading. The test did not demonstrate finished businesses, net job additions, or population growth. Following the load, simulation speed was manually set back to quadruple speed, as automatic retention was not part of the system.
Handling Missing and Incomplete Data
According to the code review, the server-side check before order acceptance still permits an unknown switch state. The building agent applies a stricter standard: prior to building mutations, complete matching responses and a fresh finding immediately before execution must confirm that the error bypass is disabled. Incomplete, missing, or unknown values block the intervention.
Similarly, queries covering spatial areas include data regarding completeness and coverage. If a metric is omitted from a partial response, it remains categorized as unknown. Missing employment or occupancy figures were not replaced with zeroes in the data collector, avoiding the misrepresentation of incomplete responses as zero values.
Current Status and Remaining Scope
Northstar MCP v0.2.1 remains active for qualified functions as of 12:29 UTC on 14 September 2026. The documented evidence covers specific operations: eleven adapter tests were passed and reproduced, but deliberately activating the error bypass and testing time-critical state shifts were not conducted in the live environment.
The catalog of 36 tools indicates available definitions rather than verified operational scope. There is no broad clearance for road construction, individual building placement, demolition, budget adjustments, policies, or districts. Furthermore, the tests provide no evidence regarding system load, long-term stability, or scaling. The building agent can perform qualified actions through the interface and inspect the immediate results. Determining the long-term impact on traffic, utilities, or urban growth requires subsequent game measurements.