Northstar MCP up to 0.7.15: more tools, narrow approvals

Since the 0.4.0 pilot, the Northstar MCPMCP Model Context Protocol, an open protocol through which an AI model calls tools and reads data from other software. interface for the CS2 city Northstar has grown from about three dozen listed tools to more than 60 under version 0.7.15, which is currently active. The count describes the interface's breadth, not its reliability or any gain in simulation performance. What matters here is which responses were actually read back in the running game and where each check stopped.

Two intermediate packages were examined on 22 September but not adopted as production-tested versions. During the attempt with the later of the two, Windows redirected a file access, and the real installation remained 0.7.7. This was an installation and integration finding, not a demonstrated fault in the new game mod. Only with 0.7.15 did independent checks confirm the physical install location, the package and backup checksums, and then the identity of the runtime that was actually responding.

Why a version change is more than copying files

The switch to 0.6.0 showed the risk. The package itself had been checked, but on the following start the game updated itself to a different build. The interface loaded and could read, yet the matching compatibility check for write actions in the game world was missing. Those actions were suspended rather than treating a successful read as a general approval.

Later switches therefore tied package identity, game build and the live tool list to a saved game, an orderly restart, a reload and a fresh readback. After each load, quadruple game speed had to be restored and verified. Since 0.7.15, normal write actions are intended only within the specifically qualified scope, with a pre-check, backup, preview and proof of preservation. No blanket approval of all new tools follows from this.

Three cases of the new evidence discipline

A batch is complete only once it is read back. Under 0.7.6, two zoning actions ran on cells that were already zoned correctly. Both child jobs were read back as observed and durably logged; calling again in the same instance reported a replay without a new submission. That is concrete protection against double execution on the tested normal path. It is not a test of a crash during writing, nor proof that arbitrary batch actions are safe.

"Complete" needs a point in time. Under 0.7.15, a new problem overview returned all intended phases, but a total assembled across several game frames was not atomic, so the first warning evaluation was not accepted as an exact snapshot. A separate complete single-frame capture then counted 128 distinct messages. Many rows are not automatically a precise state at one moment.

A reported zero is not always a reliable zero consumption. On 24 September, 39 companies with input warnings were examined in full, while 41 raw-material rows each reported zero in the consumption field. This telemetry is flagged as suspect: delivery volumes, recipes, costs and timing are missing for an all-clear. The zeros are not presented as proof that the city needs no raw materials or that its supply chains are healthy.

Observed versus assumed effects

The newer versions did not simply add commands. At several points they make it possible to separate an observed effect from an assumed one: a paginated warning list from an incomplete page, a durable batch status from a mere job acceptance, a reachable road from a working delivery. Under 0.7.7, for example, a multi-page warning query, a zoning batch and a demolition with a limited preservation check were read back live. That, too, qualifies only the cases tested.

Status

As of 24 September, 0.7.15 is genuinely in production, but the existing evidence would not cover a comprehensive approval of the full city control. Open are chiefly crash recovery, individual resource and delivery semantics, comprehensive load tests and the effect of all new write tools in a city of a million.