take_screenshot

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

Annotations declare non-read-only, non-idempotent, non-destructive, so the description appropriately adds the details they cannot: authenticated bridge requirement, the 1.5 MB inline-image cap with RPGMV_INLINE_IMAGES=0 opt-out, timestamped per-capture filenames, and the returned shape. It doesn't say where files accumulate over time or whether repeated captures collide, a minor gap.

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?

The core action, output, and prerequisites are front-loaded in the first two sentences, and nothing is padded. The prose is dense with clauses and parentheticals, but each sentence still carries usable information.

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, the description compensates by naming the return shape {path, bytes, mimeType, name} and the inline image block, plus the full prerequisite sequence. For a 9-parameter tool with two modes (playtest capture vs headless mapId render), the description is largely complete, though the mode split between screenshots/ and renders/ destinations could be stated more cleanly.

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 89%, so the schema already documents all nine parameters including the mapId mode, switches, showEvents, and showPlayer semantics. The description only adds that `name` becomes a safe filename prefix and that captures keep a timestamp, which is marginal added meaning over a high-coverage schema.

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 precise verb+resource scoped to RPG Maker MV playtest frames captured through the MCP bridge, and names the output artifact (.mcp-cache/screenshots/ PNG). It is clearly distinguishable from siblings like record_video, analyze_image, or query_map without opening schemas.

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?

Gives an explicit prerequisite chain (manage_system actions install_bridge_plugin, bridge_start, playtest) and notes the compatibility alias manage_system {action:"bridge_screenshot"}. It stops short of stating when NOT to use it (e.g., versus record_video for motion capture), so it falls just under full routing guidance.

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