Only MCP lists tools from Operation Catalog; the admin REST routes call their operations directly through Operation Runner. Yet the catalog checks every operation when the server starts (snake_case name, unique name, destructive implies write) and throws on a failure, so one bad name aborts startup for matches and the admin panel too. 20 of the board's 33 elements depend on it, only 2 directly.

Impact: A typo in any operation name, in any module, keeps the game server from booting, although the REST path never needed the catalog.

Recommendation (small effort): Keep the naming checks, but run them in a unit test over every Operations provider so a bad name fails in CI. At startup, log and skip an invalid operation rather than throwing, so MCP loses one tool instead of the server failing to boot.

Each MCP tool is an operation with a zod input schema that carries field titles and descriptions from contracts. The MCP SDK validates arguments, then OperationRunner validates again with refinements. Refusals return as tool results a model can act on. World writes and import_questions take dryRun, every write names expectedVersion, and destructive operations carry destructiveHint. These are the schema and correction loops an agent needs.

Schema discipline is the strongest of the seven concerns here; identity, provenance and the human escape hatch are the gaps.

The audit writes one op.call line per call: operation, transport, outcome, principal and user agent, but never inputs. Stored settings, worlds and questions carry version and updatedAt but no author. Once an agent has saved, nothing records what it changed or that it was an agent. Yet settingsChange already computes a list of what changed (section, key, from and to) for every settings save.

Impact: Recording who changed what turns agent edits into reviewable history, the precondition for letting agents write outside development.

Recommendation (medium effort): Store the actor (transport and principal) on each saved record, and log the settingsChange list with each settings write; add an equivalent field diff for worlds and questions.

Compose refuses to start the server without ADMIN_TOKEN, sets MCP_ACCESS to off, and the image sets NODE_ENV=production. Caddy forwards only /api, /ws and the web app, so the health probe stays inside the Compose network. If MCP is later opened read-only, list_questions and get_question strip the answer key for read-only callers.

These defaults only hold for the Compose path. Running the built server any other way skips them, which is why the development defaults above matter.

Without ADMIN_TOKEN, the admin guard lets every caller in whenever openWithoutToken is set, and loadAdminAuth sets that flag to NODE_ENV !== 'production' (server-config.ts:29, admin.guard.ts:31). Only the server Dockerfile sets NODE_ENV=production (line 20), so the Compose deployment is safe. Any other way of running the built server without that variable serves an open admin API, whose settings, worlds and questions come through Contracts and Game Core.

Impact: A server started outside the image with no NODE_ENV and no ADMIN_TOKEN lets anonymous callers rewrite game rules, worlds and the question bank, answer keys included.

Recommendation (small effort): Invert the default: open only when NODE_ENV is explicitly 'development' or 'test', and refuse to start without ADMIN_TOKEN otherwise. Add a test for the unset-NODE_ENV case.