playcal
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PLAYCAL_GODOT | No | Path to the Godot binary, used instead of putting Godot on PATH. | |
| PLAYCAL_OWNER | No | Default owner name for `playcal lock` commands, saves typing `--owner`. | |
| PLAYCAL_HISTORY | No | Set PLAYCAL_HISTORY to write the run history somewhere else, or to `off` to write nothing. By default runs are recorded in .playcal/history.jsonl. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
playcal tools, which when (playcal X below is the tool playcal_X):
Before anything in a Unity project:
playcal doctor. It says whether the CLI and an open Editor are reachable.Any Editor write (create, set_field, save_scene, recompile):
playcal loop run NAME -- ARGSwith--verifyand--expect. Never callunity commanddirectly for a write; a success during a domain reload is not a landed change.Scripts changed:
playcal loop run ... --compile, thenplaycal logs --since "Reloading assemblies"for the first cause.Something is red in the console:
playcal logsfirst, it collapses repeats and names the first cause.Big command output:
playcal queryto keep only the fields you need instead of reading the whole hierarchy.Moved, renamed, copied or deleted files under Assets/ outside the Editor:
playcal metabefore Unity imports them.Before a risky step:
playcal checkpoint save;playcal loop run --checkpointdoes it for you.Does it still run:
playcal observe(press Play, diff the scene, collect errors),playcal visual checkfor a screenshot diff.Playtest data:
ingestvalidates,reportsummarizes,calibratepredicts human pass rates from bot runs.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| playcal_assetsB | check texture import settings (.meta / .import) against a folder policy: type, mipmaps, Read/Write, compression, max size, offline |
| playcal_audioB | check audio import settings (.meta / .import) against a folder policy, and WAV loudness (LUFS), true peak and clipping, offline |
| playcal_baselineA | keep a perf baseline (p95 frame time, GC, memory) and fail only when a run is worse by more than noise |
| playcal_calibrateB | predict each level's human pass rate from bot runs, calibrated on a small human panel, with 95% intervals |
| playcal_checkpointB | save project files to a private git ref before each step, and restore any save |
| playcal_doctorB | check Python, git, the Unity CLI, open Editors and the SDK before a run |
| playcal_ingestB | validate gameplay events (JSONL or pasted PC0 blobs) against the event schema |
| playcal_lockB | lock scenes and assets so several agents don't edit the same file at once |
| playcal_logsB | summarize a Unity log: collapse repeats, show the first cause |
| playcal_loopB | run a Unity Editor command safely: wait until ready, run, wait again, one digest |
| playcal_metaA | find .meta and GUID damage (copied, moved or missing .meta files, missing scripts) before Unity imports it, without an Editor |
| playcal_observeB | press Play, run the game a few seconds, diff the scene and collect console errors; screenshot only on red |
| playcal_playtestC | run observe N times: a checklist of pass/fail/skip per run, red vs flaky (inconclusive), runs saved as PC0 events for calibrate |
| playcal_queryC | pick a list, filter it and keep only the fields you need from a big JSON result |
| playcal_replayB | record input through the SDK, replay it as a regression test with fixed frame rate and seed, step frames |
| playcal_reportB | per-level pass rate, attempts and quit rate with 95% Wilson intervals |
| playcal_snapC | save a JSON read under a name and diff two saves, with ids that change between sessions left out |
| playcal_testsB | test result history: spot flaky tests, fail CI only on real failures, run only affected test assemblies |
| playcal_uiC | draw the run history (loop, observe, replay, visual) as one static HTML page, newest first |
| playcal_visualB | screenshot gate: compare a PNG to a saved baseline with a per-pixel tolerance, write a diff PNG on a fail |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Most tools target clearly distinct concerns (meta/asset/audio checks, perf baseline, visual diff, replay, report), and descriptions are explicit about scope. The main overlap risk is among the run-related tools (loop, observe, playtest, replay), plus report/calibrate/tests, but the descriptions differentiate them well enough for an agent to choose.
All 20 tools use a consistent `playcal_` prefix with a single short lowercase word, which is predictable and readable. There is minor inconsistency in part of speech (verbs like observe/ingest/lock mixed with nouns like logs/meta/assets), but the pattern itself is uniform.
20 tools is on the heavy side for a single server, but the domain is broad (environment setup, import checks, play runs, replay, visual/perf gating, reporting, calibration, collaboration). Each tool covers a distinct workflow step, so the count is justified rather than bloated, though it sits at the upper end of comfortable.
Coverage is broad: setup (doctor), safety (checkpoint, lock), import validation (meta, assets, audio), execution (loop, observe, playtest, replay), gating (visual, baseline, tests), and analysis (logs, report, calibrate, ingest, ui). Minor gaps exist around baseline lifecycle management (e.g., explicitly updating/replacing a saved baseline) and test/checklist authoring, but agents can work around these.