Skip to main content
Glama

ZeroMind (OrigoZero game engine)

world.connect

Pin the engine of the world editor the user has open, so engine tools (execute, capture, …) drive it for the rest of this conversation. An engine that is already connected returns at once. It is held only for an engine that is about to connect: once the editor has drawn its first frame the call holds, up to about 30 s, until the engine connects. In every other case it answers at once with connected: false and what the editor is doing (editor.state: never_opened, launching, booting, connecting, stalled, failed, started_not_connected), so while an editor is still loading do what needs no engine and call this again when you need one. waited_ms is how long the call was held (0 when it was not) and wait says how the wait ended. It opens nothing: nothing on the server can open a browser. Call world.open first and act on its next, which says whether you show the user a link or run a command on their machine. A world with engines on more than one branch is refused rather than guessed at: name the branch, or use session.list / session.connect to pick one engine outright.

Input Schema

NameRequiredDescriptionDefault
guidNoThe same argument as `world`, under another name: give one of the two. A call giving them two different worlds is refused.
worldNoOptional: the guid of the world whose editor you mean (world.list names each of your worlds beside its guid). Omitted, any open editor. A value that is not a guid, a world's name included, is refused and connects nothing.
branchNoWhich branch's engine you mean, when the world has engines on more than one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / world / description
      Previous value: -"Optional: the guid of the world to wait for (world.list names each of your worlds beside its guid). Omitted, any open editor. A value that is not a guid, a world's name included, is refused and connects nothing."New value: +"Optional: the guid of the world whose editor you mean (world.list names each of your worlds beside its guid). Omitted, any open editor. A value that is not a guid, a world's name included, is refused and connects nothing."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Adds rich behavior beyond the annotations: the blocking semantics (up to ~30 s, held once the editor draws its first frame), the non-blocking path returning connected: false with editor.state, waited_ms and wait, and the multi-branch refusal. Annotations cover safety hints only; the description carries the temporal and failure behavior.

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?

Purpose and the blocking rule are front-loaded, and most sentences carry distinct procedural information. It is dense and runs long with several clauses (e.g. the server-cannot-open-a-browser tangent) that could be tightened without loss.

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?

No output schema exists, so the description must explain returns — and it does, enumerating connected, editor.state (with all values), waited_ms and wait. Combined with the routing to world.open, it is complete for calling this tool 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 clarifies relationships the schema states separately: guid and world are aliases and a mismatch is refused, omission means 'any open editor', and branch is only required when engines span branches. That adds real selection semantics over the field descriptions.

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 opening sentence states a specific verb and resource: pin the engine of the open world editor so engine tools (execute, capture) drive it for the conversation. It distinguishes itself from siblings world.open (which opens) and session.connect/session.list (which pick an engine outright), so an agent can route correctly without opening schemas.

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 covers when to use ('call this again when you need one') and when not ('while an editor is still loading do what needs no engine'), and names alternatives: call world.open first and act on its next; use session.list / session.connect for multi-branch worlds. Nothing is left to inference.

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.