dream-creo-mcp

Overview Schema Source Related Servers Discussions Admin

feature_suppress

Temporarily hide model features by ID or name without deleting them; suppress child features by default and restore them later with feature_resume.

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.

Temporarily hide features (ids or names) without deleting them; children are suppressed too unless with_children=false. Undo with feature_resume.

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>",
      "features": "<features>"
    },
    "name": "feature_suppress"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Part name without .prt
`features`	Yes	Feature ids or names
`with_children`	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 well: it discloses child-suppression behavior, reversibility via feature_resume, the requirement to call model_save for persistence, and how to verify results with model_info and preview_image. It does not explain downstream dependency behavior or what the call itself returns, leaving some mutation semantics unclear.

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 behavior appears only at the end, after a large shared preamble about units, axes, mirroring, save behavior, and result checking. Much of that preamble is generic boilerplate and not all of it is relevant to feature_suppress, so the definition is poorly front-loaded and padded.

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?

The description covers the key operational context for a mutation tool: what is hidden, child behavior, how to undo, and that changes are not saved unless model_save is called. It points to model_info and preview_image for verification, though without an output schema it could say more about the direct return value.

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?

The schema already documents name and features, but the description adds useful semantic detail by clarifying that children are suppressed by default unless with_children=false. It also reinforces the expected part-name and feature-identifier formats.

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 specifically states that this tool temporarily hides features by id or name without deleting them, suppresses children unless with_children=false, and that feature_resume reverses it. However, the actual purpose is buried after a long generic preamble, and the opening sentence 'Creates/edits geometry' is a misleading framing for a suppression tool.

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 clearly distinguishes temporary suppression from deletion and names feature_resume as the undo path. It does not explicitly say to use delete_feature for permanent removal, but the contrast with 'without deleting them' makes the alternative usage understandable.

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