editor_statusChecks whether the RPG Maker MV editor is running and reports which server-written files were changed by the editor.
Check whether the RPG Maker MV editor appears to be running and which files this server wrote have since been changed by something else (usually the editor saving over them). Report only: it never blocks or undoes any edit.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.5.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does real work: it declares the tool is purely diagnostic, that it never blocks or undoes edits, and that a nonzero result usually means the editor saved over server files. Missing only details of the report's shape or how detection is confirmed.
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 tight sentences; the primary check is first, the file-divergence case second, and the read-only caveat last. No filler.
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?
With no output schema and no annotations, the description carries the burden, and it covers purpose plus read-only safety. It stops short of describing what the report contains (e.g., list of changed paths, running/not-running flag), which is the one thing an agent must guess.
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?
The tool takes zero parameters, so the baseline of 4 applies; nothing in the description could add parameter meaning, and it correctly implies no arguments are needed.
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?
States a specific check: whether the MV editor is running plus which server-written files have diverged, with the likely cause (editor saving over them) named. It is clearly distinguishable from playtest_status and the changeset/backup tools, though it does not name any sibling explicitly.
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?
The purpose implies when it is useful (detecting external/editor edits to files the server wrote), and 'Report only: it never blocks or undoes any edit' steers agents away from expecting remediation. But there is no explicit 'use this before X' or 'use restore_backup instead if you want to revert', so timing and alternatives remain inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.