Run an editor action

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

Adds substantial behavior beyond the annotations: quit loses unsaved changes, cleanup deletes the server's screenshots/traces/logs, dialogs without a matching button are left open, fill_dialog 'never presses a button', and engine-source screenshots go black while the scene editor is in front. One caveat: destructiveHint=false is arguably loose given quit and cleanup, though both are explicitly gated (confirm=true) and warned about, so I do not treat it as a hard contradiction.

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?

Nearly every clause maps to a distinct action, so the word count is largely earned for a 16-action dispatcher. The structure is poor, though: one dense run-on paragraph with nested parentheses instead of a scannable list, and the cleanup sentence is tacked on at the very end after the 'with the bridge' group.

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, no structured param help beyond the schema, and 17 parameters, the description carries a lot and does it reasonably well, including light return-value notes ('returns the image', 'read everything back'). It stops short of describing failure modes, bridge-install prerequisites, or how errors/partial results are surfaced.

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% and every parameter's description already names the action it belongs to ('raycast: end point', 'prefix: list_commands', 'confirm: quit'). The description adds the cross-action rule that editor/file dialogs only answer to a named `button`, but otherwise restates what the schema carries, so the baseline 3 applies.

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 opening clause names the resource (the running Modding Kit editor) and the description enumerates every one of the 16 actions with a concrete gloss (console runs a command, raycast returns a hit point, perf samples frame times). An agent can tell what each action does. It does not, however, position itself against siblings such as editor_status, editor_play or read_logs, so sibling routing is left to inference.

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?

Prerequisites and conditions are stated explicitly: 'needs the bridge' for live actions, and a clean split of which actions work without the bridge (screenshot, dialogs, dismiss_dialogs, fill_dialog) versus only with it (perf). It even routes one case away to another tool: 'new files need the Resource Browser's Import new asset'. Missing is explicit when-to-use guidance versus the sibling editor_* tools.

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