Skip to main content
Glama
AstroQuestStudio

catia-v5-mcp

by AstroQuestStudio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

catia_drawing_add_dimension

Add a linear, diameter, or radius dimension to a CATIA V5 drawing view at specified coordinates, with offset and orientation controls.

Instructions

Add ONE dimension to a view, in view coordinates (u, w) (mm, model scale, see catia_drawing_add_view). type='linear': from and to points, orientation horizontal | vertical | aligned, the dimension line is placed offset_mm (paper) away on side (below/above for horizontal, right/left for vertical, left/right of the from->to direction for aligned). type='diameter' or 'radius': centre and diameter/radius of the circle, leader at leader_angle_deg. Take the values from the model (catia_list_faces gives cylinder radii and axes), never from memory: the dimension shows the value you give, the tool cannot attach it to the generated edge; catia_drawing_check compares it with the PDF. ISO 129-1: one dimension per feature, keep dimension lines >= 10 mm from the outline (offset_mm default 10), each following line 7 mm further. prefix e.g. '4x ' for identical holes. Returns JSON {dimension, type, value_mm, expected_mm, line}; a value that differs from the request by more than 0.005 mm removes the dimension and fails.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNolinear: second point [u, w].
fromNolinear: first point [u, w].
sideNo
typeYes
viewYesView name (see catia_drawing_info).
centreNodiameter/radius: circle centre [u, w].
prefixNoText before the diameter/radius symbol and value, e.g. '4x ' is written before the diameter symbol.
radiusNoradius dimension: the circle radius, mm.
drawingNoName of the CATDrawing document (default: the active document).
diameterNodiameter dimension: the circle diameter, mm.
offset_mmNoDistance of the dimension line from the feature, paper mm.
orientationNohorizontal
allow_duplicateNodiameter/radius: allow a second dimension of the same value in the view (refused by default, ISO 129-1).
leader_angle_degNodiameter/radius: direction of the dimension line, degrees counter-clockwise from +u.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial behavioral context beyond the annotations: it discloses the JSON return shape, a precise failure mode (value differs by >0.005 mm removes the dimension and fails), and the key limitation that the dimension displays the supplied value rather than attaching to generated edges. These details materially help an agent predict outcomes and handle errors, while the annotations already cover mutability and idempotency.

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

Conciseness4/5

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

Front-loads the core action ('Add ONE dimension') and organizes remaining details by dimension type and constraint. It is dense and somewhat run-on, but every sentence adds operational information for a complex 14-parameter tool, so there is little waste.

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

Completeness5/5

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

Complete for a mutation tool with no output schema: it describes the return value, failure behavior, source-of-truth requirement, coordinate system, and relevant drafting standards. An agent has enough context to call the tool correctly without needing to inspect other structured fields.

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?

With 14 parameters and 79% schema description coverage, the description contributes meaningful semantics for many parameters, including coordinate meaning (u,w in model scale), orientation behavior, side placement, leader angle for radius/diameter, and ISO spacing rules for offset_mm. Some parameters, such as drawing and allow_duplicate, rely mainly on the schema, so it does not fully compensate for every gap.

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?

States a specific verb and resource: 'Add ONE dimension to a view' and enumerates the supported dimension types (linear, diameter, radius) with their required geometry. It distinguishes itself from related tools by referencing catia_list_faces for source values, catia_drawing_check for verification, and catia_drawing_add_view for coordinate context.

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?

Gives clear procedural guidance: values must be taken from the model, not from memory, and it cites ISO 129-1 placement rules and the offset default. However, it does not explicitly state when to use this manual dimensioning tool versus the sibling catia_drawing_generate_dimensions, leaving that alternative to inference.

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