dream-creo-mcp

Overview Schema Source Related Servers Discussions Admin

find_geometry

Find faces and edges in a Creo part by feature, type, orientation, size, or proximity to a point, returning references for geometry modeling and edits.

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.

Find faces or edges to reference. kind=faces: filter by feature, face_type (plane, cylinder, cone, torus, revolved, fillet), normal (outward, planes: +x,-x,+y,-y,+z,-z). kind=edges: filter by feature, of (edges bounding surface:N), edge_type (line, arc, circle). sort by max_x/min_x/max_y/min_y/max_z/min_z/max_size/min_size; limit (default 20). near=[x,y,z] sorts by distance to that model point and returns distance (e.g. the face nearest a point you know). Returns refs with centre, normal or end points, size.

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>",
      "kind": "<kind>"
    },
    "name": "find_geometry"
  }
}

Input Schema

Name	Required	Description
`of`	No
`kind`	Yes
`name`	Yes	Part name without .prt
`near`	No	Model point [x, y, z] in mm
`sort`	No
`limit`	No
`normal`	No
`feature`	No
`edge_type`	No
`face_type`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.1Nov 6, 2026

TDQS

A3.8/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 disclose a lot beyond the schema: the return payload ('refs with centre, normal or end points, size'), the limit default of 20, and the fact that near additionally returns a distance. The surrounding preamble also supplies units (mm/degrees), part-naming rules, and axis orientation, though much of that is family-level context rather than behavior of this specific query.

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?

Roughly half the text is a generic preamble about creating/editing geometry, the absence of a mirror tool, units, axes, rollback, and model_save that has nothing to do with finding faces or edges. The actual tool documentation is deferred to the second paragraph, so the description is badly front-loaded for an agent deciding whether to call it.

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 10-parameter query tool with no annotations and no output schema, the description covers nearly every parameter and explicitly sketches the return shape (centre, normal or endpoints, size), which is the main gap it needed to close. Remaining gaps are modest: the meaning of the free-form feature filter, behavior on no matches, and any prerequisite that the part must already be open.

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 description coverage is only 20%, so the description must compensate and it does: kind semantics, face_type (plane, cylinder, cone, torus, revolved, fillet), normal signs with the note that it is the outward normal on planes, edge_type, the 'of = edges bounding surface:N' relationship, all eight sort values, limit default, and near's distance-return behavior. This adds meaning well past the bare enums in the schema.

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, 'Find faces or edges to reference,' gives a specific verb plus resource, and the kind=faces/edges split plus type filters make the query intent unambiguous. It loses a point because the description opens with 'Creates/edits geometry... through the DreamFeatureApp plugin,' a mutation framing that does not describe this lookup tool and can mislead on first read; it also never names a sibling (e.g. measure, model_info) for contrast.

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

Usage Guidelines3/5

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

Usage is only implied: 'to reference' suggests this feeds later feature calls, and the 'near=[x,y,z] ... e.g. the face nearest a point you know' example gives a concrete scenario. There is no explicit when-to-use/when-not guidance and no statement distinguishing it from measure or model_info, which also probe model data.

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