Fetch a PNG preview of a 3D model using its model ID, choosing from perspective, front, top, or right views to instantly visualize the design in your client.
Return an actual PNG image to the MCP client. Views: perspective, front, top, right.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | perspective | |
| model_id | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of transparency. It clearly states that the tool returns a PNG image and lists the supported views, which implies a read-only operation with no side effects. It does not explicitly state that it makes no modifications, but the 'get' nature and the return of an image make this reasonably clear.
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 highly concise, consisting of just two short sentences. It gets straight to the point without unnecessary elaboration. The key information—the return type and the available view options—is presented clearly and efficiently.
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 must explain the return type, which it does by stating 'an actual PNG image'. It also covers the main input parameter (view) with its possible values. It does not address error cases or edge situations, but for a simple preview retrieval, the description is sufficiently complete for an agent to understand what it does.
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?
The schema provides no descriptions for parameters, so the description must compensate. It partially does: it enumerates valid values for the 'view' parameter ('perspective, front, top, right'), which is helpful. However, it does not explain that 'model_id' is required, what it represents, or that 'view' has a default value. This leaves about half of the parameter semantics undocumented.
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's purpose: returning an actual PNG image to the client. It also lists the available views, making it obvious that this is a preview function. This distinguishes it from sibling tools like get_model or get_model_source, which likely return data rather than image binaries.
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 implies usage for retrieving previews but does not explicitly say when to use this tool versus alternatives like get_model or get_model_source. It does not mention any conditions or scenarios where this tool is preferred or not. The guidance is implicit rather than explicit, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.