NullG's MCP harnesses expose native engine tools to AI agents, scripts and test runners. They can inspect a track or model, control the camera, run simulation cases, capture screenshots and export race video. The viewers use the game's asset loaders and renderer, so inspection happens against the runtime assets.
A Python MCP server manages native tools and headless jobs, saving inputs, screenshots, reports and logs for each run. A reported problem can be reopened with the same inputs rather than reconstructed from a screenshot alone.
Track inspection
The native track viewer opens assets directly, without setting up a race. MCP controls move the camera, seek through animation and switch diagnostic views, with the result visible in the native window.
Geometry, textures, hierarchy and animation can be inspected together. Findings retain their source asset and sample, making a particular track section or animation frame reproducible.
Simulation and streaming checks
Track tests isolate jumps, braking, hover, traffic or lap progression. They run the production simulation alongside independent geometry checks. Short cases make a problem easier to repeat, while full-track tests check whether the behaviour holds beyond that section.
Failed cases retain their inputs, phase traces, asset hashes and executable identity. Rendering the same case connects the report to the ship's movement and the surrounding geometry.
Streaming needs its own checks. The tools compare complete and streamed geometry from the same camera and animation sample, using masks and reports to locate differences.
Model inspection
A model can load successfully and still be facing the wrong way or have a material that looks nothing like it did during authoring. The model viewer checks hierarchy, materials, posed bounds and texture references, and can hold a view still while switching between color, normals, UVs, wireframe and bounds. Original models and objects from imported archives use the same controls.
For the rebuilt XL ships, this means opening the GLBs used by the game and comparing them with the original ships from matching camera positions. Close views show panel seams, fasteners, paint, exposed metal and canopy glass. Rear and underside views cover parts that are easy to miss from a chase camera.
The viewer can hold steering and airbrake inputs to inspect cosmetic control-surface movement. Menu and race captures then check the model at gameplay scale and under different lighting.
Wireframe and bounds views expose mesh density, scale and orientation errors before the model is used in a race.
Imported models, including the ships in XL archives, load through the production adapters with their associated textures. That keeps the inspection tied to the assets the game actually loads.
Source behaviour
REA exposes reverse-engineering tools through MCP for investigating XL / 2097 controls, regional timing, physics, weapons and animation.
Adapted behaviour is exercised through the engine's simulation harnesses and viewers. Saved cases can be rerun as the implementation changes.
Replays and video
Replays record authoritative race state in .ngreplay files. The cinematic director follows racers and events, chooses chase framing and handles camera cuts. It can use human races, all-AI runs and reinforcement-learning evaluations.
Learning evaluations can save both results and replays under the experiment identity. The replay shows the steering, recovery or weapon choice behind a score, making it possible to investigate why a candidate improved or regressed.
The replay_video.py tool renders landscape, portrait and square videos. It handles trimming, racer focus, playback speed, camera seeds, titles, overlays and transitions, then checks audio, video and frame counts before completing the MP4. The source replay and report are kept with the export.