Render an existing OBJ mesh to a PNG preview using CPU-only matplotlib, enabling quick visual inspection of generated 3D geometry without GPU rendering.
Render an existing OBJ file to a PNG preview (matplotlib Agg, CPU only).
| Name | Required | Description | Default |
|---|---|---|---|
| obj_path | Yes | ||
| output_path | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full disclosure burden, and it does add real context: the matplotlib Agg backend and CPU-only rendering tell the agent this is a lightweight, headless, non-GPU path. It does not cover failure behavior for missing/invalid OBJ files or whether the render is a low-fidelity approximation, which leaves meaningful gaps.
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?
A single front-loaded sentence with the verb, input, output, and runtime constraints packed in. Every clause adds information; nothing is wasted.
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?
An output schema exists, so return values need not be explained, and the tool is simple with only two parameters. Still, with zero annotation and zero schema-description coverage, the description should resolve the output_path default and file-existence expectations, and it does neither.
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, and it only loosely maps the two parameters: the OBJ file corresponds to obj_path and the PNG output to output_path. It never explains what an empty output_path (the schema default) does, which is the main ambiguity an agent would hit.
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 verb and resource (render an existing OBJ file) plus the output format (PNG preview), which is enough to tell it apart from script-oriented siblings like render_script and preview_script. It does not explicitly name those siblings, so it falls short of a 5.
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 phrase 'existing OBJ file' implies this tool is for files already on disk rather than for scripts, which is an implicit cue versus render_script/preview_script. However, it never states when to choose this over those alternatives or any exclusions, so the guidance stays at the implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.