viewport_capture_screenshot

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

No annotations are provided, so the description must disclose behavioral traits. It mentions forwarding `show_ui` and `resolution` to the native screenshot command, which is useful, but it omits details about whether the operation is blocking, whether it requires an active viewport, side effects on the editor state, or error conditions like invalid directory. The tool is a write operation (creates an artifact), but no side effects are disclosed.

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 description is compact with a clear structure: a one-sentence summary, a parameter list, a returns line, a KB reference, and an example. It front-loads the core purpose. The KB reference adds useful context, though it could be seen as extra for some agents. Overall, it is appropriately sized with minimal fluff.

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?

The tool is moderately complex with 4 parameters, no annotations, and an output schema that lists filepath, dimensions, size, and hash. The description fails to explain what the output JSON structure looks like in detail (though output schema covers this), but more critically, it does not clarify when to use this tool versus similar siblings, and it lacks detail on error handling or prerequisites. The KB reference provides depth but at the cost of immediate understandability. For an agent deciding to use this tool, the missing usage guidance and behavioral caveats are significant gaps.

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 0%, so the description must explain each parameter. It gives one-line descriptions: 'Screenshot filename stem' for artifact_name, 'Workspace-relative output directory' for screenshot_dir, and 'Forwarded to the native screenshot command when supported' for show_ui and resolution. While these provide basic meaning, they lack specifics like allowed formats for resolution, the meaning of 'filename stem' in terms of extension handling, and any constraints on directory paths. This is minimal compensation for zero schema coverage.

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 the tool captures the active Unreal viewport to a PNG artifact, with explicit mention of the resource (active viewport) and the output artifact. It is distinguishable from the sibling `take_screenshot` and `viewport_compare_screenshot` by its specific focus on the active viewport and PNG artifact, though it doesn't explicitly contrast these siblings.

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?

No explicit guidance is provided on when to use this tool versus alternatives like `take_screenshot` or `viewport_compare_screenshot`. The description does not mention conditions for use or mention alternatives for comparison, leaving the agent to infer its purpose from the name alone.

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