dream-creo-mcp

Overview Schema Source Related Servers Discussions Admin

model_save

Saves the open Creo part to a specified absolute folder as name.prt.N, writing a backup copy when the folder differs from the original location.

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.

Save the model to dir (Creo writes name.prt.N). If dir is the folder the model came from it is a real save (method=save, modified=false); otherwise a copy is written there (method=backup) and the open model stays modified. Never uploads to Windchill.

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>",
      "dir": "<dir>"
    },
    "name": "model_save"
  }
}

Input Schema

Name	Required	Description	Default
`dir`	Yes	Absolute folder for the .prt file
`name`	Yes	Part name without .prt

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.1Nov 6, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the load and does well: it discloses the written filename convention (name.prt.N), the save-vs-backup branch, the resulting modified flag, and the no-Windchill-upload boundary. Undisclosed are overwrite behavior when name.prt.N already exists and what happens on an invalid or unwritable dir.

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

Conciseness2/5

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

The tool-specific save semantics appear only in the second paragraph, buried behind a long preamble about extrudes, revolves, patterns, units, and datum axes that has nothing to do with saving. Only "Nothing is saved unless model_save is called" from that preamble earns its place. The content is under-structured rather than over-long, but the front-loading failure is severe.

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?

For a two-parameter write tool with no output schema, the description covers the destination semantics, the artifact naming, the post-call state of the model, and an external boundary (Windchill). It even points at model_info and preview_image for verification afterward. Nothing an agent needs in order to call this correctly is absent.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond it: dir is not merely "absolute folder" but a semantic switch that determines whether the operation is a save or a backup, and name determines the emitted file name. That is decision-relevant semantics the schema does not convey.

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 operative sentence is precise: "Save the model to dir (Creo writes name.prt.N)" — a specific verb, resource, and destination format. However, roughly half the description (geometry creation, mirror absence, units, axis orientation) describes feature-building tools rather than model_save, diluting the signal. The "Never uploads to Windchill" line does implicitly separate it from model_export without naming the sibling.

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 dir conditional is genuine decision guidance: if dir is the source folder the agent gets a real save (modified=false), otherwise a backup copy (method=backup) that leaves the model modified. What's missing is explicit routing — it never says to prefer model_export for external transfer or model_close for teardown, leaving alternative selection to inference.

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