su-unity-walkthrough
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| root | Yes | Absolute path to the workspace root, passed as the --root argument. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| environment_inspectB | Discover local software without installing/upgrading it. Does not inspect unsaved windows. |
| project_createB | Create a new draft config from saved SKPs. Paths use the workspace root; input files stay read-only. Provide an existing URP/Input System/Pipeline Unity project. Entries/doors are filled after inventory. |
| config_readB | Read config, its optimistic edit token, current fingerprint, and whether entries are still unreviewed. |
| config_saveC | Validate and save a draft before any scene generation. Changed scenes require a new config/output/scene revision. |
| config_validateC | Check schema/source hashes; after inspect, resolve exact instance selectors and visibility before assembly. |
| inventory_queryC | Page current instances/visibility. Use ground-corrected unity_origin/unity_bounds for config; raw origin/native preserve source zero. Units are metres. |
| stage_startB | Start one persistent local job and return promptly. Reuse an operation ID only for the identical request. Stages: preflight, convert, inspect, assemble(sample), verify(sample), assemble, verify, build. |
| job_getB | Read a persistent receipt and bounded log tail. Running/unknown is not authorization to redispatch. |
| job_reconcileB | After a worker stops, reconcile only current terminal engine/Unity evidence. Never clears unresolved work. |
| review_recordC | Bind actual observations to current sources/config/scene/build. States: passed, failed, not_applicable, untested. source: saved_disk_source (must pass). configuration: visibility, entries, doors, routes. sample: scale, materials, enclosure, door_motion. standalone: launch, walk, look, interaction, escape_reset, model_entries, display_settings, materials, player_log. Explain any not_applicable item in evidence; do not mark an unobserved behavior passed. |
| workflow_statusC | Rehash current artifacts; summarize stage evidence, manual observations, coverage and delivery readiness. |
| standalone_launchC | Launch this run's current verified Mac build as a new app instance. Launch request is not input verification. |
| preview_controlC | Observe a current saved scene in Play Mode: capture screenshot, advancing frames and performance samples. Preserves dirty scenes, refuses other running scenes; stop only this config's preview before another stage. |
| report_readC | Read one Unity report with paged checks and exact input fingerprint. Missing reports remain missing. |
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 14 tools
Most tools target clearly distinct pipeline stages (config lifecycle, inventory, staging, review, preview, launch, reports). A few boundaries are fuzzy: job_get vs job_reconcile vs workflow_status all report on job state, and environment_inspect vs inventory_query both surface local state, though descriptions do differentiate them.
Nearly all names follow a noun_verb pattern (config_read, job_get, review_record, preview_control). The lone irregularity is workflow_status, which uses a noun instead of a verb, but overall the convention is predictable.
Fourteen tools map cleanly onto the pipeline's phases—discovery, config, inventory, staging, reconciliation, review, verification, and reporting—with no obvious padding. Each tool earns its place.
Coverage is strong across the walkthrough lifecycle: config create/read/save/validate, inventory, multi-stage jobs, review recording, status, launch, preview, and report reading. Minor gaps exist—no explicit job cancel/abort, no report listing, and no cleanup/teardown for created artifacts—but agents can likely work around them.