undo_world_prunePut the world files from before the most recent prune back (the node keeps backups of the changed files). The server must be stopped.
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | The server id (server_...) from list_servers. |
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| restored_files | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description adds useful context beyond annotations: the node keeps backups and the server must be stopped. This provides operational context without contradicting the annotations. Not full score because it doesn't detail side effects like overwriting current files, though the destructive hint covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core action comes first, then the essential precondition. Every word contributes meaning, and it is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, rich annotations, and a clear precondition, the description is complete. It covers what, why, and when, and there is no missing information an agent would need to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single 'server' parameter fully explained as a server id from list_servers. The description adds no additional parameter-level semantics, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('put back') and resource ('world files from before the most recent prune'), distinguishing it from the sibling prune_world. It also explains the backup mechanism, leaving no ambiguity about what operation is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states a critical precondition: 'The server must be stopped.' This tells the agent when the tool is usable. It does not name alternatives explicitly, but the context of pruning/restoring makes the intended use clear enough, and the exclusion of running servers is direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Every tool targets a distinct resource and action: server lifecycle, backups, files, console, stats, player activity, and VPS power operations are clearly separated. Even similar reads (get_server vs get_live_stats vs get_player_activity) have well-defined scopes.
All tools follow a consistent verb_noun snake_case pattern (create_server, list_backups, restart_server, power_vps). The verbs are clear and the naming style is uniform throughout.
17 tools is slightly above the ideal 3-15 range but appropriate given the dual scope of game server management and VPS management. Each tool covers a meaningful operation without being bloated.
The tool surface covers the primary workflow: discovering servers, managing lifecycle, backups, files, and console access. Minor gaps exist (no restore backup, no server settings update, no delete server) but these are likely intentional safety boundaries and do not block core usage.