Skip to main content
Glama

ZeroMind (OrigoZero game engine)

tool_exec

Destructive

Run a JavaScript script inside the engine, against the engine's own tool catalogue. Use this instead of several separate tool calls whenever you need to filter, loop over, or combine results: the intermediate data stays in the script rather than passing through the conversation.

Two globals, and nothing else:

zero..(...args) call a tool. Every call returns a promise, so await it. zero.libs...(...args) call a tool a library ships (its toolbox is registered as @::) tools.toolboxes() every toolbox: { toolbox, purpose, toolCount } tools.list(toolbox) the tools in one: { name, signature, description } tools.describe(name) one tool in full: args, returns, examples, types tools.search(query, toolbox?) find a tool by what you want to do tools.use(toolbox, tool, ...args) call by computed name

Start with tools.toolboxes() or tools.search(...) if you do not already know the tool you want, then tools.describe(name) for its exact arguments: they are positional and typed. zero. also reaches a library's toolbox when no other toolbox has that name; a name several hold is refused naming each. await works at the top level. return a value to hand it back; keep it small, and reduce inside the script rather than returning everything you fetched. console.log is captured and returned in logs. The language is ZeroJS: modern JavaScript and its standard library, with no Node or browser APIs.

Sequencing is yours to choose: await a; await b; runs them one after another, while await Promise.all([a, b]) runs them at the same time, which genuinely overlaps, so prefer it for independent calls.

The answer is { ok, value, error, failure, trace, logs }. value is what the script returned. When ok is false, error says what failed and where, and failure.kind is tool (a tool call's rejection ended the script; failure.step and failure.tool name the call), script (the script threw), syntax (it did not parse; the position counts the script's own lines), timeout (it outlived timeoutMs; a value it had returned stays in value), budget (it made more than 200 tool calls) or setup (the script environment could not be prepared). trace lists every call with its step, outcome and duration.

Example:

const hits = await tools.search("read a file"); const [info, text] = await Promise.all([zero.wld.info(), zero.files.read("/source/notes.md")]); return { mode: info.mode, lines: text.split("\n").length, firstHit: hits[0].name };

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.
scriptYesThe JavaScript to run. `await` works at the top level; `return` hands back the result.
timeoutMsNoWall-clock budget for the whole script, including its tool calls. Default 30000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations declare this is not read-only, is open-world, and is destructive, so the safety profile is already stated. The description adds substantial context beyond them: the 200-tool-call budget, timeout semantics, the failure.kind taxonomy, trace/log capture, and sequencing guidance for parallel calls. It does not warn that the script itself can make state-changing calls, which is the one behavioral note a mutation-capable tool of this kind should make explicit.

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?

The purpose statement is front-loaded, and the API reference block and error taxonomy earn most of their space for a meta-tool with a custom DSL. Some material is redundant with the schema (the top-level `await` note repeats the script parameter description), and the note about name collisions with library toolboxes is niche.

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, but the description fully specifies the return envelope ({ok, value, error, failure, trace, logs}) and the meaning of each failure kind. For a complex, DSL-carrying tool this is complete enough to call correctly on the first attempt.

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% and the `as` parameter is already documented in depth, so the baseline is 3. The description still adds real value — it warns that tool arguments are positional and typed and directs the agent to tools.describe for exact arguments, plus the 'keep the return small / reduce inside the script' guidance for the script parameter.

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?

Opens with a specific verb and resource: 'Run a JavaScript script inside the engine, against the engine's own tool catalogue.' It also distinguishes the tool from the obvious alternative of making many individual tool calls. However, it never contrasts itself with the sibling execution tools (bash, execute), which an agent must choose between for the same basic job.

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?

Explicit when-to-use: 'Use this instead of several separate tool calls whenever you need to filter, loop over, or combine results.' It also gives an in-script discovery path (tools.toolboxes / tools.search / tools.describe). There is no explicit when-not-to-use case (e.g. a single simple call), though that is strongly implied.

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.