dream-creo-mcp

Overview Schema Source Related Servers Discussions Admin

datum_plane

Create a datum plane in Creo by offset from a reference plane or by angle through an axis or edge, then sketch on it by feature name.

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.

Datum plane. mode=offset: parallel to ref at offset mm (negative = other side). mode=angle: through axis/straight edge 'thru', at angle degrees to plane 'ref'. Returns its surface id; sketch on it by feature name.

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>",
      "mode": "<mode>",
      "ref": "<ref>"
    },
    "name": "datum_plane"
  }
}

Input Schema

Name	Required	Description
`ref`	Yes	Datum name (FRONT, TOP, RIGHT, DTM1...) or an id from find_geometry/model_info: surface:N, edge:N, axis:N
`mode`	Yes
`name`	Yes	Part name without .prt
`thru`	No	Datum name (FRONT, TOP, RIGHT, DTM1...) or an id from find_geometry/model_info: surface:N, edge:N, axis:N
`angle`	No
`offset`	No
`feature_name`	No	Optional feature name

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 full burden and does reasonably well: it discloses that each feature call ends with an active feature or is rolled back, that nothing persists until model_save, and that the call returns a surface id usable for sketching. It does not cover failure modes, required permissions, or regeneration behavior.

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

Conciseness3/5

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

The tool-specific content (three sentences on modes, return value, naming) is tight, but it is preceded by a long shared preamble about axes, units, rollback and saving that pushes the actual datum-plane semantics to second position rather than front-loading them.

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

Completeness4/5

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

For a 7-parameter creation tool with no output schema and no annotations, the definition supplies the essentials: units, reference addressing, mode geometry, return value, and persistence semantics. What is missing is direction-convention detail (which side is positive relative to 'ref') and error/rollback conditions.

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 57%, so the description must add meaning and largely does: it explains that 'offset' is in mm with negative going to the other side, that 'angle' is in degrees relative to plane 'ref' and pivots on axis/straight-edge 'thru', and that units globally are mm/degrees. feature_name is only obliquely covered via 'sketch on it by feature name' rather than as the optional naming argument.

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 description names the resource (datum plane) and specifies both creation modes with their geometric meaning: offset-parallel-to-ref and angle-through-thru. An agent can tell this apart from extrude/revolve siblings, though it never explicitly contrasts itself with them, leaving it just 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.

Usage Guidelines4/5

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

Mode selection is well guided (offset vs angle with the exact reference each needs), and the preamble adds workflow rules: no mirror tool, build symmetry with extrudes/revolves/patterns, check results via model_info and preview_image. There is no explicit when-not-to-use-this-tool statement or sibling routing, so a 4 rather than a 5.

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