Skip to main content
Glama

ZeroMind (OrigoZero game engine)

zeromind.inspect

Read-only

What worlds or assets found via zeromind.search say they are, from their metadata. Pass SEVERAL guids at once: a whole shortlist is one call, not five. It carries no content bytes; an asset's read is the command that starts reading its implementation in the engine's bash (zm ls-tree @<guid>, then zm grep / zm show / zm log), which is how you tell whether it does the job before you install it. AN ASSET answers with guid, name, assetType (plus type_guid when the type is somebody's own, which is the only way to name one), summary — what the thing is, in prose — description and readme, the author's own words and more of them than a search hit carries, tags, schema/provides_schema, about (what its own metadata says it HAS: the components a bundle spawns with, whether its rig is a humanoid one), the world it lives in with that world's title and licence, its owner (with owner_bot when that account is an agent's), counts of what other people did with it, votes, created/updated, and latest — the version an install pins, and the day it was written; issues when something stands open against it; and read, the zm command that starts reading its code. An asset with a preview image also answers with preview_description (what the preview shows, in words) and returns the thumbnail itself as an image block beside this JSON, at most 4 per call: images names the guid each image block belongs to, in order, and images_omitted names the guids left out and why. A WORLD answers with title, summary, description, owner, license, visibility, the branch a read resolves to and the others it has, counts, votes, dates, and published: what it publishes, in the order its own listing ranks it, each with its own summary. A field with nothing in it is absent rather than empty. results matches the guids by position; one that is private, deleted, or of the other scope is reported against that guid and does not fail the rest.

Input Schema

NameRequiredDescriptionDefault
guidYesOne guid, or several separated by commas ('a,b,c'), from search hits. Up to 100 per call.
sortNoview=published only: hot | top | popular | new.
viewNoHow much to return per guid. ASSETS: 'overview' (default) = everything that decides reuse, and 'detail' is the same answer; 'similar' = the assets nearest this one in the index, each projected as a search hit with its `similarity`, for when the hit was close but not right. WORLDS: 'overview' (default) = the world and what it publishes, in one call; 'summary' = the world alone, without its shelf; 'published' (alias 'contents') = just the listing, which is what `assetType`/`sort`/`limit` narrow.
limitNoHow many entries per guid for the list-shaped views (world published, asset similar). Not a cap on how many guids you may pass — that is 100.
scopeNoWhat these guids ARE: 'assets' (default) or 'worlds'. The same two values zeromind.search takes.
assetTypeNoview=published only: narrow a world's listing to one or more asset types. Builtin types by name, anything else by its type guid.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the readOnly/openWorld/non-destructive annotations, it discloses that no content bytes are returned, that at most 4 preview images come back with the `images`/`images_omitted` accounting, that absent fields are omitted rather than empty, and that a private/deleted/other-scope guid is reported per-guid without failing the rest of the call. That is exactly the kind of failure-mode and payload-shape context annotations cannot carry.

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 in the first sentence, but the body is a very long, densely packed enumeration of every return field with inline commentary. Since no output schema exists this documentation has value, but the wall-of-text presentation makes it hard to scan and several clauses restate schema-level facts.

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?

With no output schema, the description carries the full burden of documenting returns, and it does so exhaustively for both the asset and world result shapes, plus error isolation and image-block behavior. For a 6-parameter, two-scope tool of this complexity, an agent has everything needed to call and interpret it.

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 description coverage is 100%, so the schema already documents all six parameters (including the rich `view` mode semantics and the 100-guid cap). The description reinforces some of this (asset `similar`, world `published`, image limit) but adds little syntax or format detail the schema lacks, so baseline 3 applies.

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

Purpose4/5

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

The description states a specific resource and operation: reporting what worlds/assets 'say they are, from their metadata', keyed on guids from zeromind.search. It explicitly distinguishes itself from content reading ('carries no content bytes') and points to `read`/bash for implementation, so siblings are differentiated. The opening construction is indirect and wordy, which keeps it short of a 5.

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 concrete usage guidance: 'Pass SEVERAL guids at once: a whole shortlist is one call, not five', and names the `similar` view for 'when the hit was close but not right'. It also implies the pre-install inspection workflow ('how you tell whether it does the job before you install it'). What is missing is an explicit when-not-to-use statement versus zeromind.search and zeromind.preview.

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.