ZeroMind (OrigoZero game engine)

search_tools

Read-only

Search the Zero tool registry. Tools are named, typed operations grouped into toolboxes (entityOps, scene, appearance, lighting, …). With no arguments, returns the toolbox overview — one row per toolbox with its purpose and tool count. toolbox returns all of that toolbox's tools; query on its own searches every tool and toolbox this world can reach — its own, the builtin library, installed libraries and imports — by meaning (mode: "semantic") or by words (mode: "keyword"), and answers the top 25 compact rows: the callable identity, whether the hit is a tool or a toolbox (drill into a toolbox with toolbox), and a one-line purpose. The answer names the mode and slot that ran, the worlds it covered, and its status. A query given with a toolbox searches inside that toolbox's registered tools instead. Pass schema: true on a toolbox drill-in for full signatures, args, and examples inline, or call describe_tool for one tool's full schema. Run a result with tool_exec. Answered by the attached engine, so it needs one: world.open attaches one. guides answers without an engine.

Input Schema

Name	Required	Description
`as`	No	Your 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.
`from`	No	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.
`mode`	No	semantic finds tools by what they do; keyword matches the words in each tool's README and code. Default: semantic on a live engine, keyword offline.
`limit`	No	Optional cap on the number of results. On the `toolbox` drill-in it is a trim, not a ceiling — omit it to return EVERY tool, since compact rows stay small and a genuinely large listing spills to a retrievable file rather than being silently truncated. A query answers the top 25 ranked hits; a smaller limit trims them.
`match`	No	What a hit must match: the README (identity), the code and its declared interface (capability), either (any, default), both (all).
`query`	No	One phrase, as a string, naming what you are looking for in plain words. On its own it searches every tool and toolbox this world can reach (its own, the builtin library, installed libraries and imports) and answers compact rows. Given WITH a `toolbox` it instead matches the words of that toolbox's own registered tools, and `mode` / `match` do not apply. Omit (with no `toolbox`) to browse the TOOLBOX overview: one row per toolbox with its purpose and tool count.
`schema`	No	Include each tool's full schema (signature, args, returns, examples) inline. Applies to the `toolbox` drill-in; a `query` answers compact rows — the callable identity plus a one-line purpose. Fetch one tool's full schema on demand with describe_tool.
`toolbox`	No	Drill into one toolbox — return its tools (e.g. entityOps, camera, lighting, baking). Call with no arguments first for the list of toolbox names. With a `query`, the search runs over that toolbox's registered tools rather than over the content this world can reach.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

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"
+}

First observedOct 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses prerequisites (needs an attached engine; world.open attaches one), the shared-connection identity model for `as`, the fact that keyword mode reads unpushed private files, and that large listings spill to a retrievable file rather than being silently truncated. It also previews the answer's metadata (mode, slot, worlds covered, status).

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?

It is front-loaded with purpose and the overview behavior first, then branches to drill-in and query semantics. The prose is dense and some sentences carry multiple clauses, but nearly every sentence conveys a distinct behavior rather than filler.

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 8 parameters, zero required, and no output schema, the description carries the return-shape burden itself by describing the compact rows (callable identity, tool vs toolbox, one-line purpose) and the appended answer metadata. Prerequisite and mode-default behavior are covered, so an agent can call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema cannot: query alone searches everything reachable while query+toolbox scopes to that toolbox and nullifies mode/match, and limit is a trim on queries but not a ceiling on toolbox drill-ins. This relational context is genuinely additive.

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 first sentence names a specific verb and resource ('Search the Zero tool registry') and immediately explains the three operating shapes: no-argument toolbox overview, `toolbox` drill-in, and standalone `query`. It distinguishes itself from siblings by naming describe_tool for single-tool schemas and tool_exec for running results.

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?

Explicit routing is given: use `schema: true` on a toolbox drill-in or call describe_tool for one tool's schema, run hits with tool_exec, and note that `guides` answers without an engine. When-not conditions are stated (query with toolbox bypasses mode/match; keyword offline default), leaving little to inference.

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

All ZeroMind (OrigoZero game engine) tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

search_tools

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources