Render the active viewport as a PNG image and return it for inspection. Use distinct filenames per pose to avoid overwrites, with optional width, height, and overwrite control.
Render a PNG of the active viewport and return it as an MCP image. Use distinct filenames per pose.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| width | No | ||
| height | No | ||
| overwrite | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds little behavioral context. It does not state that a file is written to the specified path, how overwrite=false behaves, or whether the scene is modified. The filename tip indirectly hints at overwrite risk but leaves the actual file-saving behavior ambiguous.
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 concise and front-loaded with the core action, followed by a single tactical tip. It is brief and does not ramble, but the brevity omits important parameter and behavior details. Still, every sentence earns its place.
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?
For a tool with 4 parameters, no output schema, and no parameter descriptions, this description is incomplete. It does not clarify the role of the required path parameter, the meaning of overwrite, or the failure behavior when the file already exists, leaving an agent to 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?
Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It only hints at path usage ('Use distinct filenames per pose') and says nothing about width, height, or overwrite semantics, leaving most parameters unexplained.
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 states a specific action, 'Render a PNG of the active viewport,' and the return format, 'return it as an MCP image.' This clearly distinguishes it from sibling tools such as export_fbx or set_view_mode, making the tool's purpose unambiguous.
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 description provides no guidance on when to use this tool versus alternatives like export_fbx or get_camera. The only usage note, 'Use distinct filenames per pose,' addresses repeated captures but does not help an agent decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.