dream-creo-mcp

Overview Schema Source Related Servers Discussions Admin

sketch_curve

Creates open or closed datum curves on a plane for sweep trajectories or profile geometry; define lines, arcs, circles, and centerlines in model coordinates (mm).

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.

Sketched datum curve on a plane, open or closed (no material). Use it as a sweep trajectory by its feature_name. Example path on FRONT: 'M 0 0; L 0 60; A 20 80 20 60 cw; L 60 80'. Sketch path, commands separated by ';'. Recommended: coords=model, then every point is 'x y z' in model coordinates (mm) and is projected onto the sketch plane, so it works the same on any plane. Commands (p = point): 'M p' start a loop; 'L p' line to; 'A3 p m' arc to p passing through m; 'A p c ccw|cw' arc to p around centre c; 'Z' close the loop; 'C c r' circle; 'CL p q' centerline (revolve axis). Example coords=model on FRONT: 'M -50 -25 0; L 50 -25 0; L 50 25 0; L -50 25 0; Z'. Default coords=sketch (1.0): points are 'x y' in the sketch frame (on FRONT = model X, Y; on other planes see sec_location in the result). Solid features need closed loops; open loops and a revolve without exactly one CL are rejected before Creo is called.

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>",
      "plane": "<plane>",
      "sketch": "<sketch>",
      "feature_name": "<feature_name>"
    },
    "name": "sketch_curve"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Part name without .prt
`plane`	Yes	Datum name (FRONT, TOP, RIGHT, DTM1...) or an id from find_geometry/model_info: surface:N, edge:N, axis:N
`coords`	No	Point format of sketch: model = 'x y z' model coordinates (recommended)
`sketch`	Yes
`orient_ref`	No	Datum name (FRONT, TOP, RIGHT, DTM1...) or an id from find_geometry/model_info: surface:N, edge:N, axis:N
`feature_name`	Yes	Optional feature name

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.1Nov 6, 2026

TDQS

A4.2/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 unit conventions (mm and degrees), model axis orientation, that points are projected onto the sketch plane, that calls either end with an active feature or are rolled back, that nothing persists unless model_save is called, and that invalid loops are rejected before Creo is invoked. It does not describe the returned payload beyond a passing reference to sec_location, and gives no idempotency or naming-collision 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 content is valuable but the structure buries the tool-specific definition behind a paragraph of global Creo/plugin conventions (mirror absence, save semantics, rollback) that applies to many siblings. Two long worked examples covering much the same ground add bulk, and the command grammar is dense prose rather than a list.

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 six-parameter geometry tool with no output schema and no annotations, the description covers units, coordinate semantics, command grammar, validation failures, persistence, and how to verify results via model_info and preview_image. The main omission is any explanation of orient_ref and of what the call returns (feature name, plane frame) beyond the sec_location hint.

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 83%, so baseline is 3; the description goes beyond it by explaining the coords enum semantics (model = 'x y z' projected onto the plane vs sketch = 'x y'), the full sketch command grammar with worked examples, and how plane/FRONT/TOP/RIGHT axes map to model axes. The orient_ref parameter is never explained in the description, leaving that gap to the schema's terse note.

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

Purpose5/5

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

The description states a specific verb and resource: "Sketched datum curve on a plane, open or closed (no material)", and explicitly distinguishes it from the sweep sibling by saying it supplies the trajectory "by its feature_name". An agent can tell what this creates and what it does not (no material, no mirror) without opening any schema.

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?

It gives clear usage context: use the sketch's feature_name as a sweep trajectory, prefer coords=model because points are projected onto the plane, and it names the workaround when no mirror exists (symmetric extrudes/revolves/patterns). It also states rejection conditions (open loops, revolve without exactly one CL). It stops short of explicitly routing to extrude/revolve/sweep for material-bearing geometry.

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