Skip to main content
Glama

nx_create_dimension

Creates an associative linear dimension with bilateral tolerance between two selected model edges in a drafting view, measuring horizontal, vertical, or parallel distance.

Instructions

Create an associative linear dimension with a bilateral tolerance.

Measures the distance between two model edges (selected by their 0-based index from nx_list_edges on the given body) inside the drafting view. Default tolerance is ±0.1 mm using the BilateralTwoLines style.

Input Schema

NameRequiredDescriptionDefault
pos_xNo
pos_yNo
body_idNo
view_idNo
dim_nameNoMCP_DIMENSION
measurementNohorizontal
lower_toleranceNo
upper_toleranceNo
first_edge_indexNo
second_edge_indexNo

Output Schema

NameRequiredDescriptionDefault
statusNosuccess
messageYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the dimension is associative, uses BilateralTwoLines style, and defaults to ±0.1 mm tolerance. However, it does not disclose mutation effects on the drafting view, failure conditions for invalid body/view/edge selections, or other operational constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and compact: the core action is stated first, followed by measurement scope and default tolerance behavior. There is no redundant or filler text.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although an output schema exists and return values need not be described, this is a complex 10-parameter creation tool with no annotations and 0% schema description coverage. The description covers the main concept but omits enough parameter meaning and operational detail that an agent may not know how to populate or safely invoke several inputs.

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

Parameters2/5

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

Schema description coverage is 0% across 10 parameters, so the description must compensate. It explains the edge-index parameters, body/view context, and tolerance defaults, but leaves pos_x, pos_y, dim_name, and the measurement enum unexplained, which is a significant gap for a 10-parameter tool.

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: create an associative linear dimension. It also scopes the operation to measuring distance between two model edges inside a drafting view, which differentiates it from radius/diameter dimension tools and from a plain distance measurement.

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 establishes the usage context: create a linear dimension between two body edges in a drafting view, with edges selected by index from nx_list_edges. It does not explicitly state when not to use this tool or name alternatives such as nx_measure_distance or the radius/diameter dimension tools.

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