holonovel

Parser Command

run_command

Destructive

Execute parsed RPG commands to mutate persistent, audited game state; resolve movement outcomes without changes, or map intents to recommended tool calls.

Instructions

Run the spatial parser: execute a parsed command, resolve a movement outcome, or map an intent to tool calls. execute accepts free-form text, mutates world and entity state, persists, and is audited; a mistaken move is reversed by issuing the inverse command because no undo snapshot is taken. resolve computes the same movement without mutating, and suggest returns recommended calls without executing them; source and target apply only to perception queries. On a ruleset-bound Novel the parser is GM-only for navigation and mutation, while the Player badge keeps read-only perception commands. Use when: a player or narrator takes a physical action, needs a movement outcome without mutating, or wants intent mapped to tools. Do NOT use when: the GM creates or edits the model — use manage_world; durable world facts — use manage_lore.

Input Schema

Name	Required	Description
`action`	No	execute (parser), resolve (non-mutating intent), suggest (intent → tool calls), visibility (can one actor see another or a thing), or audibility (can one actor hear another). Defaults to execute.
`intent`	No	The intent to resolve or map (resolve/suggest).
`source`	No	Observing actor for visibility/audibility (defaults to the active entity).
`target`	No	Actor or thing being seen or heard (visibility/audibility).
`command`	No	The natural-language command (execute).
`entity_id`	No	Optional entity context (suggest).

Output Schema

Name	Required	Description	Default
`text`	No	Human-readable text envelope mirroring the structured result (REQ-001, REQ-548a).
`status`	Yes	Machine-readable result status: OK, NEED_INPUT, WARNING, PARTIAL, or an error category (REQ-002, REQ-548c).

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv2026.10.13Oct 25, 2026

changedInput schema / properties / action / description

Previous value: -"execute (parser), resolve (non-mutating intent), or suggest (intent → tool calls). Defaults to execute."New value: +"execute (parser), resolve (non-mutating intent), suggest (intent → tool calls), visibility (can one actor see another or a thing), or audibility (can one actor hear another). Defaults to execute."

changedInput schema / properties / action / enum

Previous value: -[
-  "execute",
-  "resolve",
-  "suggest"
-]New value: +[
+  "execute",
+  "resolve",
+  "suggest",
+  "visibility",
+  "audibility"
+]

addedInput schema / properties / source

Added value: +{
+  "description": "Observing actor for visibility/audibility (defaults to the active entity).",
+  "type": "string"
+}

addedInput schema / properties / target

Added value: +{
+  "description": "Actor or thing being seen or heard (visibility/audibility).",
+  "type": "string"
+}

Addedv1.0.3Sep 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that execute mutates world and entity state, persists, and is audited; that no undo snapshot is taken so a mistaken move must be reversed with the inverse command; and that resolve/suggest are non-mutating. It also states an authorization rule (GM-only navigation/mutation on a ruleset-bound Novel, Player badge limited to read-only perception) that no annotation conveys. This is consistent with destructiveHint=true and readOnlyHint=false.

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?

Front-loaded with the mode breakdown before the operational caveats, and every sentence carries content (mutation/persistence, no undo, permission model, use/don't-use). It is dense and long for a description, but the density is justified by five distinct modes; splitting the permission sentence out would improve scannability.

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?

An output schema exists, so return values need no explanation; the description instead covers the dimensions that matter for a destructive, multi-mode, permission-gated tool: which action mutates, how to recover from a bad mutation, and who is allowed to call it. Nothing material is missing for correct invocation.

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 baseline would be 3, but the description adds cross-parameter meaning the schema does not: which modes consume free-form text ('execute accepts free-form text') and the scoping rule that 'source and target apply only to perception queries'. That conditional applicability is genuinely useful for avoiding wasted arguments on resolve/suggest.

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 and resource ('Run the spatial parser') and then enumerates the three primary modes - execute, resolve, suggest - plus the perception modes visibility/audibility. It explicitly separates itself from manage_world and manage_lore, so an agent can pick it out of a crowded 34-tool sibling list without opening the schema.

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?

Contains explicit 'Use when:' triggers (a player or narrator takes a physical action, needs a movement outcome without mutating, wants intent mapped to tools) and explicit 'Do NOT use when:' exclusions that name the correct alternatives (manage_world for model creation/editing, manage_lore for durable world facts). This is the when/when-not/alternatives pattern at full strength.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.