Skip to main content
Glama

ZeroMind (OrigoZero game engine)

world.restore

Recover a soft-deleted world before it's permanently purged. Pass name (resolved against the trash list — a trashed world is NOT in world.list) or guid (e.g. from world.trash). Owner-only. 404s if the world was already purged.

Input Schema

NameRequiredDescriptionDefault
guidNoAlready-resolved world guid (skip lookup)
nameNoTrashed world name (looked up via world.trash)
worldNoThe same argument as `guid`, under another name: give one of the two. A call giving them two different worlds is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnly false, destructive false, openWorld true, non-idempotent false), and the description adds real context on top: owner-only authorization, trash-list resolution semantics, and a 404 if the world was already purged. It omits what happens on a repeat call or when multiple trashed worlds share a name.

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

Conciseness5/5

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

Three tight sentences, no filler, with the core recovery action and its time-limited nature front-loaded before the identifier guidance.

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?

For a mutation tool with no output schema, the description covers the essentials an agent needs: identifier options, permission requirement, and failure mode. Non-idempotent retry behavior and name-collision handling remain unexplained but are minor.

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 baseline is 3; the schema already documents `guid`, `name` lookup, and the `world` alias with its conflict-refusal rule. The description adds some resolution nuance but never mentions the third `world` parameter, so it does not exceed the schema.

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 ('Recover a soft-deleted world') plus the scope boundary ('before it's permanently purged'). It is clearly separable from siblings like world.trash, world.undraft, and world.list.

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?

Explicitly routes the agent to the right identifier source: `name` resolved against the trash list, or `guid` 'e.g. from world.trash', and warns that a trashed world is NOT in world.list. It also states the owner-only precondition and the 404 outcome, though it never names a competing alternative tool (e.g. world.undraft) to disambiguate against.

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.