Skip to main content
Glama

ZeroMind (OrigoZero game engine)

by ai.origozero
OverviewDiscussionsAdmin

bash

Destructive

A complete bash shell running inside the Zero engine, over this world's files and the engine's live state. It runs in the engine, apart from the computer you are called from. Use it the way you use bash on any development machine, and reach for what you already know first: the shell language is all there, and the standard programs are installed (ls /usr/bin lists them). command not found means only that one program is absent; do that job another ordinary way.

Where things are: the world's project is /zero/source, the engine's live state is /zero/runtime (as files), the engine's documentation is /zero/docs (and man <topic>). /tmp is scratch for the session; ~ is your home, kept on this machine and synced to no one.

The engine's own operations are a command-line program, zero. Learn it as you would any unfamiliar CLI: zero --help, zero --search <query>, zero <toolbox> <tool> --help. zm is the world's version control, with the git verbs. luau <file> runs a Luau script in the engine.

For example: rg -n 'typed function' /zero/source find /zero/source -name '*.luau' | xargs grep -n 'asset.resolve' COUNT="$(find /zero/source -type f | wc -l)"; echo "$COUNT" mkdir -p /tmp/work && grep -rn 'TODO' /zero/source > /tmp/work/todo.txt find /zero/runtime -maxdepth 2 -type d zero --search 'raycast' zero camera --help

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.
commandYesThe command line, written exactly as you would type it into bash anywhere else: pipelines, redirection, `$(...)`, quoting, globs, loops and multi-line scripts all work.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, and the description adds substantial context beyond them: the shell runs inside the engine not on the caller's machine, /tmp is session scratch, ~ is local-only and 'synced to no one', and `command not found` means only that one program is missing. This is unusually rich operational disclosure.

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 is front-loaded, and the layout (where things are, the `zero`/`zm`/`luau` CLIs, then worked examples) is scannable. It is on the long side, but most sentences carry distinct information rather than padding.

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?

For a complex, open-ended shell tool with no output schema, the description supplies everything needed: filesystem layout, discoverability via `--help`/`--search`, scratch/home semantics, and examples. An agent can invoke it correctly without further context.

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; the description adds meaning by explaining what the `command` string can contain (pipelines, redirection, $(...), globs, loops, multi-line scripts) and by tying the `as` parameter to the notion of a per-caller shell session. It reinforces but does not fully re-document the parameters, which is appropriate.

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?

Opens with a specific verb+resource: 'A complete bash shell running inside the Zero engine, over this world's files and the engine's live state.' It distinguishes itself from siblings like execute/read_file/write_file by framing itself as a full shell over the world's files, so an agent understands it is not a task-specific helper.

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 strong positive guidance ('Use it the way you use bash on any development machine, and reach for what you already know first') plus concrete examples, and tells the agent where things live. It stops short of naming when to prefer siblings like execute or read_file over running a shell command, so it lacks explicit exclusions.

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) toolsInspect
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.

Resources