Generate detailed visual representations of a SolidWorks model from specific views like isometric, front, or top. Capture these screenshots to verify model accuracy against reference drawings.
Images of the model from standard views (compare with a drawing, check the result).
| Name | Required | Description | Default |
|---|---|---|---|
| doc | No | Document title or path. Defaults to the active document. | |
| views | No |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. Beyond that the description adds almost nothing: it does not say what is returned (inline image data vs. files written to disk), whether multiple views produce multiple images, or the image format/resolution — critical unknowns for a screenshot tool with no output schema.
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 short sentence with no waste, and the core capability is front-loaded before the usage hint. It is perhaps overly compressed for a tool whose return value is non-obvious.
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 simple (2 optional params, no nested objects, no output schema), so the description is close to sufficient for invocation. The notable gap is the result shape — an agent cannot tell whether to expect image payloads, file paths, or written files, which is exactly what a caller needs before invoking.
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 coverage is 50%: 'doc' is fully documented in the schema while 'views' has no description but is a self-explanatory enum. The description's phrase 'standard views' loosely maps to the views parameter, but it never mentions the default-to-active-document behavior, the 1–6 view limit, or the default isometric view.
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 the resource ('Images of the model') and the scope ('from standard views'), which together with the name make it unambiguous that this captures viewport snapshots. It is clearly distinct from every sibling (no other capture/render tool exists), though the verb is implied rather than explicit.
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 parenthetical 'compare with a drawing, check the result' gives concrete use cases, which is more than most siblings offer. However, it never states when not to use it or points to an alternative (e.g., sw_print_check or sw_measure for verification), so guidance stops at implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.