dream-creo-mcp

Overview Schema Source Related Servers Discussions Admin

feature_xml_export

Exports a Creo feature's full element tree as XML so you can inspect its definition, edit values or reference IDs, and rebuild it; sketches are excluded.

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.

Advanced. Return a feature's element tree as Creo XML (the full definition: type, values, references as PRO_XML_REFERENCE_ID). Read it to learn how a user-made feature is defined, edit values or reference ids, and rebuild it with feature_xml_create. Sketches are not included in the XML.

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>",
      "feature_id": "<feature_id>"
    },
    "name": "feature_xml_export"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	Part name without .prt
`feature_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.1Nov 6, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full load and does reasonably well: it discloses the return format (type, values, PRO_XML_REFERENCE_ID references), a content exclusion (sketches), and environment semantics (feature calls end active or rolled back, nothing saved without model_save). It never explicitly labels the operation as read-only and says nothing about error behavior for an invalid feature_id, which keeps it short of a 5.

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 is efficient, but roughly half the description is generic environment boilerplate (axes, units, rollback, model_info/preview_image reminders) that applies to every sibling and does not help with an XML export. Because the actual purpose appears only after that preamble ('Advanced. Return a feature's element tree...'), the text is not front-loaded.

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

Completeness3/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 explain the return value, and it does so only at a high level: it names the fields (type, values, references as PRO_XML_REFERENCE_ID) without showing structure or size expectations. For an 'Advanced' tool whose whole point is that the agent will read and edit the returned XML, more detail on the XML shape and on how feature_id maps to a part feature would be needed.

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

Parameters3/5

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

Schema coverage is 50%: `name` is documented in the schema and reinforced by the description ('Parts are addressed by name (lowercase, no .prt)'), but `feature_id` has no schema description and the description never explains what a feature id is or where to obtain one. The mm/degrees note is irrelevant to these two parameters. It compensates for half the gap, matching a 3.

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 paragraph states a concrete verb and resource: 'Return a feature's element tree as Creo XML (the full definition: type, values, references as PRO_XML_REFERENCE_ID).' It also names its counterpart, feature_xml_create, so an agent can separate export from rebuild. The score is held below 5 only because the actual purpose is buried after a long block of shared boilerplate rather than leading the description.

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 explicit usage scenarios: 'Read it to learn how a user-made feature is defined, edit values or reference ids, and rebuild it with feature_xml_create.' It also states a limitation ('Sketches are not included in the XML') that tells the agent when this tool won't give what it needs. There is no explicit when-not-to-use statement or pointer to a non-XML alternative such as model_export.

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