Skip to main content
Glama
Sign In
dream-creo-mcp

dream-creo-mcp

by JaikenWong
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

list_dimensions

Retrieve dimensions from a Creo model to inspect or filter them by name, type, or selection state, including selecting found dimensions in Creo for downstream edits.

Instructions

本服务器只修改已经打开的 Creo，经 CREOSON 完成。CREOSON 不能草图、拉伸、打孔或圆角；新建几何用 extrude/revolve/hole/round 等建模工具。尺寸值用模型单位。工具不假定尺寸名，也不假定某次会话里的数值或包围盒。feature/list 只列可见特征，不能据此判断没有实体。除非 action 是 save，否则不会 file/save。破坏性 action 必须带精确 confirm。选择器为空或全匹配时，普通令牌不够，要对应的 ALL_* 令牌。feature/suppress 与 resume 省略 with_children 时，处理器默认 true，会连带子特征。layer/show 不会删除层。interface/export_image 的 height 和 width 在一次观察里按英寸起作用，不是像素。

Get a list of dimensions from a model. select=true clears the current Creo selection.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_dimensions"
  }
}

Input Schema

NameRequiredDescriptionDefault
fileNoFile name Default: The currently active model.
nameNoDimension name; only used if names is not given Wildcards allowed.
namesNoList of dimension names Default: The name parameter is used; if both are empty, then all dimensions are listed.
selectNoIf true, the dimensions that are found will be selected in Creo Default: false.
encodedNoWhether to return the values Base64-encoded Default: false.
dim_typeNoDimension type filter Default: no filter. Valid values: linear, radial, diameter, angular.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.1

TDQS

C2.9/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It does disclose two genuinely useful traits — that select=true mutates the Creo selection state and that dimension values use model units — but it omits whether the call is otherwise read-only, what the result contains, and how large result sets behave.

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 ten clauses of server-wide preamble — covering extrude/revolve/hole/round, feature/suppress, layer/show, and interface/export_image — do nothing for this list tool and bury the two sentences that actually matter. The tool-specific content is not front-loaded, so an agent must scan past unrelated rules to find it.

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?

With six optional parameters, full schema coverage, and no output schema, the definition is barely sufficient: an agent knows how to call it but not what a dimension record contains (name, value, type, units). The useful unit and selection-state notes partially offset the missing return-value detail.

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 description coverage is 100%, so the baseline is 3 regardless. The description adds a little beyond the schema by explaining that select=true clears the existing selection and that values are in model units, but it says nothing about the interplay of name vs names or dim_type filtering beyond what the schema already states.

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 sentence 'Get a list of dimensions from a model' gives a clear verb plus resource, and 'select=true clears the current Creo selection' adds a concrete side effect. However, it never distinguishes this from siblings such as measure or find_geometry, which an agent might plausibly reach for when hunting dimension data.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance for this tool; the reader must infer from 'Get a list' that it is the enumeration path. The long preamble gives server-wide conventions but never says why an agent would pick list_dimensions over measure or find_geometry.

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

Deploy Server

Other Tools