Skip to main content
Glama

ZeroMind (OrigoZero game engine)

guides

Read-only

Search or read the engine's built-in guides (API topics, how-tos, and each asset type's README under types/). list enumerates every guide path, path reads one, query searches them. Works with or without an engine. With one attached, that engine answers, by meaning, and also reaches the world's own guides and its installed libraries. With none, the answer comes from the published Zero docs, matched by keyword, and says so: served_by is "docs" and engine says why no engine answered.

Input Schema

NameRequiredDescriptionDefault
asNoYour own name, when you are one of several agents sharing one connection to this engine (the sub-agents one agent session runs share its connection, so without it the engine sees all of them as one caller). Pass the same name on every call you make. The engine then treats you as a caller of your own: your roster name is this name, and your play session, the play-shadow writes and refusals that say who wrote what, engine.modeOwner, your shell session and your notices are yours alone. Lowercase letters, digits, '-' and '_'. Leave it out when you are the only agent on your connection.
fromNoWHERE results may come from. 'all' (default) is everything published. 'bound' is the current world and its installed libraries, answered by this engine with no published-library leg; `mode` still picks how the query is matched, and mode='keyword' reads this engine's own files, unpushed ones and a private world's included.
listNoEnumerate all guide paths. `path` and `query` are ignored.
modeNosemantic finds content by what you are trying to do; keyword matches the words in the files each type declares — a README, a guide body, code. Default: semantic on a live engine, keyword offline. An attached engine reads it; the answer from the published docs does not.
pathNoGuide identity, e.g. topics/physics or types/shader. A short form (physics) works when only one guide answers to it. With `query`, narrows the search to the guides under this identity.
tierNoHow much of each entry the guide index (no `path`, no `query`) returns: 1 the paths alone, 2 adds each guide's kind and summary, 3 adds the file behind it and the other spellings it answers to. An attached engine reads it; the answer from the published docs does not.
limitNoMax matches to return when searching. An attached engine reads it; the answer from the published docs does not.
matchNoWhat a hit must match: what a thing IS, its README (identity); what it DOES and how it is made, a guide body or code (capability); either (any, default); both (all). Applies to keyword mode only; semantic ranking does not read it. An attached engine reads it; the answer from the published docs does not.
queryNoWhat you are looking for, in plain words.
assetTypeNoComma-separated documentation types a `query` searches: 'guide', 'agentskill', 'assettype', 'guide,assettype'. Omit to search all three. Any other type is refused: `search_tools` searches tools and toolboxes, and `zeromind.search` every other kind. An attached engine reads it; the answer from the published docs does not.
context_linesNoLines of surrounding context above and below each matched line in the snippets a `path` + `query` scan returns. An attached engine reads it; the answer from the published docs does not.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / from
      Added value: +{
      +  "description": "WHERE results may come from. 'all' (default) is everything published. 'bound' is the current world and its installed libraries, answered by this engine with no published-library leg; `mode` still picks how the query is matched, and mode='keyword' reads this engine's own files, unpushed ones and a private world's included.",
      +  "enum": [
      +    "all",
      +    "bound"
      +  ],
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/non-destructive, and the description adds real context beyond them: the degraded offline path served by published Zero docs, the returned `served_by` value of 'docs', and the `engine` field explaining why no engine answered. This is exactly the kind of fallback disclosure an agent needs.

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

Conciseness4/5

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

A single dense paragraph that is front-loaded with the core action and the list/path/query mapping before the engine-vs-offline nuance. It is long but nearly every clause carries routing or fallback information; only minor compression is possible.

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

Completeness4/5

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

With 11 optional parameters and no output schema, the description covers the critical axis (online vs. offline behavior and the `served_by`/`engine` response fields) and defers per-parameter detail to the rich schema. It stops short of describing the shape of a `query` result set, but the schema's tier/match descriptions fill most of that gap.

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%, so every parameter already carries a detailed description including the 'attached engine reads it; published docs does not' caveat. The prose largely restates the schema (mode defaults, tier meaning) without adding format or syntax beyond it, 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?

States a specific verb and resource ('Search or read the engine's built-in guides') and immediately scopes the content (API topics, how-tos, types/<name> READMEs). The three sub-operations (list/path/query) are named so an agent can distinguish them without opening the schema.

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

Usage Guidelines5/5

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

Explicitly routes to alternatives: 'search_tools searches tools and toolboxes, and zeromind.search every other kind', and it distinguishes behavior with vs. without an attached engine. The mode selection (semantic default on a live engine, keyword offline) is spelled out.

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.