Northstar MCP 0.3.0: Verified Read Operations and Qualified Release

Following a pilot test conducted on 15 September 2026, Northstar now operates on Northstar MCPMCP Model Context Protocol, an open protocol through which an AI model calls tools and reads data from other software. 0.3.0. The documented test concluded at 06:49 UTC, corresponding to 08:49 in Berlin. The pilot confirmed the new version for checked read operations, camera control, simulation speed, saving, and reloading. Separate test conditions apply before the building agent may execute further write operations.

Verification of the Active Interface and Save Procedures

Prior to the pilot run, the eight files cataloged in the package manifest were checked. Following this step, the actual installation was verified. The active client additionally verifies build identity and the version string returned in runtime responses. The final game-state response explicitly confirmed version 0.3.0.

This distinction is necessary when assessing past defects: observations recorded under version 0.2.1 describe that older version and do not disprove a subsequent correction. Conversely, developer notification of a delivered fix does not replace an in-game test. Both forms of evidence remain separate in time and substance.

During the pilot, a previously created savegame was loaded under the new version. A new save state was then recorded, its files were checked, and this save state was actually reloaded. An attempt to save under the same name without overwrite permission was rejected; the savegame hash verified immediately afterward remained unchanged. The verification of saving therefore extends beyond a mere job confirmation. After loading, simulation speed had to be set explicitly back to fourfold speed. The conclusion verified an active simulation, operational camera controls, and standard monetary and unlock rules while the error bypass remained disabled. An unbroken, unchanged state throughout the entire installation process is not claimed.

Handling Ambiguous Warning Causes

During earlier operations, a capacity warning designated as a garbage issue had originated from a cemetery. A plausible label was therefore insufficient to determine the correct public utility. For city operations, this distinction matters directly: a misassigned warning can lead the building agent to initiate an unnecessary or unfitting construction project.

The test covered eight warning groups. Seven of these groups presented an unambiguous candidate cause. For the shared capacity warning, the interface provided two candidates, while the fields for an unambiguous cause and the original source remained explicitly unknown. The recorded contract test confirms this behavior across the examined groups.

This output gives the building agent grounds for closer inspection at the specific entity rather than proceeding on an unfounded assignment. However, this finding does not constitute a full operational sign-off for all warning types. The live pilot did not encounter a case without any candidate cause.

Consistency Testing of Zoning Cells

Under version 0.2.1, raw zoning counters could register the same physical area multiple times when internal blocks overlapped. Development reported delivered corrections for version 0.3.0. The pilot evaluated an existing comparison area: both the area summary and the entity-level enumeration each yielded 102 visible cells, with 72 recorded as occupied residential cells.

This match provides evidence of internal consistency. However, the examined sample did not contain a verified overlapping double count. Furthermore, no new zoning write operation followed by a spatial comparison was carried out during the test. The original defect condition has therefore not yet undergone a complete re-test inside the game.

Prior to deploying this tool in operations, the documented procedure requires a fresh save state, a complete spatial pre-check, and an independent readback. Earlier raw counters must not serve as an unverified baseline for cell numbers in the new version. A successful read test also does not qualify road, building, or demolition tools.

Re-evaluating Fleet Counters

A developer reconciliation from 15 September 2026, concluded at 06:03 UTC, revised a previous working hypothesis: the earlier assumption that fleet.used fundamentally measures something different from the native vehicle interface is not supported. According to the documented code review, the value points to the same vehicle counter as the game interface.

Time-staggered samples showing differing figures therefore do not demonstrate a semantic difference. A simultaneous live comparison remains outstanding. This finding represents a dated clarification of the earlier interpretation rather than a retrospective change to the underlying observations. It does not imply that all questions regarding fleet utilization are resolved.

Operational Status and Open Items

The documented findings from the pilot and their remaining boundaries for the CS2 project are structured as follows:

Individual response times recorded during the test are not presented as performance improvements, as a controlled comparative baseline is lacking. Additional performance and export logging remained disabled during the pilot. Furthermore, safeguards against an intentionally enabled error bypass or timing conflicts between task acceptance and execution were not evaluated through new live counter-tests.

The current release brings verified progress for specific read and operational functions. City management and technical interface qualification remain distinct responsibilities: whether any action improves traffic flow, utility provision, or growth must continue to be evaluated through its observed effects in the city.