Skip to main content
Glama

add_sketch_dimension

Add a driving dimension to a sketch entity at a specified point. Automatically names the dimension, enabling parametric modification and linking to global variables.

Instructions

Cota de croquis — agrega una dimensión gobernante (driving dimension) a la entidad de croquis que pasa por el punto (x, y, z) dado. La cota queda nombrada automáticamente "D1@Croquis1", "D2@Croquis1", etc.

Uso típico CSWA: tras dibujar el outline del Tool Block con create_line/create_arc, agregar cotas a los segmentos clave (A=largo total, B=alto total) para luego ligarlas a variables globales y parametrizar el diseño.

[en: Sketch dimension — add a driving dimension to the sketch entity that lies at the given point. Auto-named "D1@", "D2@...", etc. Used to make a sketch parametric so its dimensions can be modified in-place (vía modify_dimension) or linked to a global variable.]

Args: entity_x_mm, entity_y_mm, entity_z_mm: A point in the part frame (mm) that lies ON the sketch entity to dimension (e.g., the midpoint of a sketch line, or a point on a sketch circle's perimeter). SW selects the closest sketch segment to this point. value_mm: The desired dimension value, in millimeters. SW first creates the dim with the entity's current geometric value, then this tool overrides it to value_mm (forcing the geometry to update). text_offset_x_mm, text_offset_y_mm: Where to place the dim text, as an offset from the entity point in mm. Cosmetic only; defaults to (20, 10) for legible callouts.

Returns: the dim's full name (e.g., "D1@Croquis1"), suitable for use with modify_dimension(sketch_name, "D1", new_value_mm) or for binding to a global variable via an equation.

Requires the sketch to be in EDIT MODE — call right after create_sketch / create_sketch_on_face and BEFORE the sketch is closed by extrude_sketch / extrude_cut.

Gotcha: SW infers the dim TYPE from what was selected (line→length, circle→diameter, two lines→angle). If you pass a point that lies on a circle's perimeter, you get a diameter dim. To force a specific type, ensure your entity_point is clearly inside one entity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
value_mmYes
entity_x_mmYes
entity_y_mmYes
entity_z_mmNo
text_offset_x_mmNo
text_offset_y_mmNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

No annotations provided, so description carries full burden. It fully discloses behavior: driving dimension, auto-naming, dimension type inference based on point selection, value override forcing geometry update, text offset defaults, and return of dim name. No contradictions.

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?

Description is well-structured with sections for purpose, arguments, returns, requirements, and gotchas. However, it includes both Spanish and English, making it slightly longer than necessary for an English-only agent.

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?

Given 6 parameters, 0% schema coverage, no annotations, and presence of output schema (not shown), the description covers all necessary aspects: function, parameters, usage flow, return value, prerequisites, and a gotcha. It is fully adequate for correct invocation.

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

Parameters5/5

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

Schema has 0% coverage, but description explains each parameter's purpose and usage: entity_x/y/z_mm as a point on the sketch entity, value_mm as desired dimension value that overrides geometry, text_offset_x/y_mm for cosmetic placement with defaults.

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?

Description clearly states the tool adds a driving dimension to a sketch entity at a given point with auto-naming. It implicitly distinguishes from siblings like add_sketch_relation and modify_dimension by focusing on dimension creation.

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?

Explicitly states the sketch must be in edit mode and should be called after sketch creation and before closing. Provides a typical CSWA use case and a gotcha about dimension type inference. Does not mention when not to use or alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/danielproxd2/MCP_CAD'

If you have feedback or need assistance with the MCP directory API, please join our Discord server