Skip to main content
Glama

ZeroMind (OrigoZero game engine)

zeromind.preview

Read-only

Preview exactly what zeromind.install WOULD write, without writing anything. Returns the resolved closure tree — every file and dependency with its local dest_path, byte size, content hash, and why it is included (root / requires / depends_on / conforms_to / tree_child) — plus rollup totals, a truncated flag and a withheld flag (true when part of the graph was left out: it lives in a world you cannot read, or its world no longer ships it, and then unshipped lists its guids). What the content references in ANOTHER world is not a node: worlds lists each such world with the commit it is pinned at and every reference site, naming the node that holds it (from) and the asset it resolved to (names). For an entry with a commit, the install brings the named assets in from that world at that commit (nothing when your world already pins that world at that commit). An entry whose commit is null brings nothing: its sites resolve against the world you install into, which must already open that library. A site marked engine_surface brings nothing either: the running engine provides it. Nodes cover what the published reference tables state and nothing more: content whose files reference assets no table recorded (often content published before the engine recorded that kind of reference) previews and installs without them. Use it on the candidate you picked, after reading its code with zm in the engine's bash, to see its footprint before you install it, especially when it pulls in dependencies you did not expect. Needs no connected world.

Input Schema

NameRequiredDescriptionDefault
atNoDestination DIRECTORY the install would use (the asset keeps its own name), used to compute each node's dest_path. e.g. at=/source/combat → /source/combat/<name>. Defaults to /source.
refNoPreview the asset at a ref, read as zeromind.install reads it: a commit id, a branch or tag of the asset's world, or one of the asset's own version ids. A ref that names none of these is an error. Omitted or empty, the preview shows what the asset's world ships.
guidYesThe root asset guid to preview (from a zeromind.search / zeromind.inspect hit).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / ref / description
      Previous value: -"Preview a specific commit id. Defaults to the latest finalized commit."New value: +"Preview the asset at a ref, read as zeromind.install reads it: a commit id, a branch or tag of the asset's world, or one of the asset's own version ids. A ref that names none of these is an error. Omitted or empty, the preview shows what the asset's world ships."
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/safe/openWorld, and the description adds substantial context beyond them: the resolved closure tree fields (dest_path, size, hash, inclusion reason), rollup totals, the truncated and withheld flags, the unshipped guid list, and cross-world `worlds` entries with commit pinning and reference sites. It also discloses a real limitation — nodes cover only what published reference tables state, so unrecorded references are silently absent from the preview.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded correctly in the first sentence, but the body is a wall of dense run-on clauses about cross-world resolution, null commits, engine_surface sites, and reference-table coverage. Every clause is substantive, yet the lack of structure makes the return semantics hard to parse on a first read.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by fully explaining the shape of the returned tree, rollups, flags and cross-world entries, plus the install semantics of each kind of entry. For a preview tool of this complexity, an agent has everything needed to call it and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents guid, ref and at in detail, so the description does not need to re-explain them. It adds indirect meaning by describing how ref semantics play out (commit/branch/tag/version resolution, null commit bringing nothing, engine_surface sites), but that is return-value context rather than direct parameter guidance, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb, resource and contrast: 'Preview exactly what `zeromind.install` WOULD write, without writing anything.' That single clause distinguishes it from its write sibling zeromind.install and states the safety-relevant difference explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a concrete workflow: use it on the candidate you picked, after reading its code with `zm` in the engine's `bash`, before installing, especially when unexpected dependencies appear, and notes 'Needs no connected world.' It never states when NOT to use it or names an alternative preview path, which keeps it short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.