dream-creo-mcp

Overview Schema Source Related Servers Discussions Admin

preview_image

Renders the active Creo model window as a JPEG for visual verification, with optional view changes, refitting, and datum display.

Instructions

Creates/edits geometry in the running Creo 5 through the DreamFeatureApp plugin. There is no mirror tool: build symmetric shapes with symmetric extrudes, revolves or patterns. Units are mm and degrees. Parts are addressed by name (lowercase, no .prt). Model axes: FRONT is the XY plane (normal +Z), TOP is XZ (normal +Y), RIGHT is YZ (normal +X). Each feature call either ends with an active feature or is rolled back. Nothing is saved unless model_save is called. Check results with model_info (volume, bound_box) and preview_image.

Render the model's window to a JPEG and return it as an image (about 3 s). Optional view turns the window first. fit (default true) refits the model; datums=true shows datum planes and axes (hidden by default for a clean picture). width/height in inches at 100 dpi (default 6 x 4). Views: front looks along -Z (model XY plane), top looks down -Y, right looks along -X, iso is the Creo default 3D orientation. An unknown view name is an error listing the saved views.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "preview_image"
  }
}

Input Schema

Name	Required	Description
`fit`	No
`name`	Yes	Part name without .prt
`view`	No	front, back, top, bottom, left, right or iso (Creo default orientation); also a saved view name. Case-insensitive.
`width`	No
`datums`	No
`height`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.1Nov 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses latency (~3 s), the output format (JPEG image), that the call can mutate window state ("Optional view turns the window first"), defaults for fit/datums/size, and explicit error behavior for unknown view names. It does not state whether the call requires an already-open part or is otherwise read-only against model data, leaving a small gap for a tool with side effects on view state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The tool-specific paragraph is dense and front-loaded, with each clause carrying real information (view directions, defaults, error case). The shared preamble is longer than this tool needs and the view options are stated twice (schema and description), but nothing is truly wasted given the environment context it supplies.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must describe the return, and it does: a JPEG image of the model window, roughly 3 s, sized in inches at 100 dpi. Combined with parameter defaults, the mutation of view state, and the error case, an agent has everything needed to call this correctly for visual verification.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33% (only name and view are documented in the schema), so the description must compensate and does: fit is explained as refitting the model with default true, datums as showing datum planes/axes that are hidden by default, width/height as inches at 100 dpi with a 6x4 default, and view gets directional semantics (front looks along -Z, top down -Y, right along -X, iso is Creo default) plus saved-view fallback beyond the schema's enum-less string.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The tool-specific sentence is precise: "Render the model's window to a JPEG and return it as an image (about 3 s)," which names the verb, resource, and output type, and implicitly separates it from view_set (which only changes orientation). However, the description opens with "Creates/edits geometry in the running Creo 5..." – a toolkit-level preamble that describes geometry features, not image rendering, so an agent skimming the first line could misfile this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The preamble explicitly positions it as a verification step ("Check results with model_info (volume, bound_box) and preview_image"), giving a clear use context, and the tool paragraph explains that the optional view turns the window first, clarifying the interaction with view_set. It stops short of stating when not to use it (e.g., cost of repeated calls beyond the ~3 s note) or how it relates to model_export for non-window output.

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