Skip to main content
Glama
Sign In
CDT AutoCAD Provider

CDT AutoCAD Provider

by SlncTrZ
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

dimension_aligned

Creates an aligned dimension entity between two WCS extension points and a dimension-line point, applying the active drawing's dimension style.

Instructions

Create an aligned dimension from WCS extension points and a WCS dimension-line point, using the active drawing's dimension style.

Side-effects: Adds aligned DIMENSION entity. Disambiguation: Dimension line stays parallel to extension points regardless of angle.

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": {
      "x1": "<x1>",
      "y1": "<y1>",
      "x2": "<x2>",
      "y2": "<y2>",
      "dim_x": "<dim_x>",
      "dim_y": "<dim_y>"
    },
    "name": "dimension_aligned"
  }
}

Input Schema

NameRequiredDescriptionDefault
x1YesFirst extension line origin X coordinate in WCS
x2YesSecond extension line origin X coordinate in WCS
y1YesFirst extension line origin Y coordinate in WCS
y2YesSecond extension line origin Y coordinate in WCS
dim_xYesDimension line definition point X coordinate in WCS
dim_yYesDimension line definition point Y coordinate in WCS
layerNoTarget layer name. Uses active layer if omitted

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.1.1
    • addedInput schema / properties / dim_x / description
      Added value: +"Dimension line definition point X coordinate in WCS"
    • addedInput schema / properties / dim_y / description
      Added value: +"Dimension line definition point Y coordinate in WCS"
    • addedInput schema / properties / layer / description
      Added value: +"Target layer name. Uses active layer if omitted"
    • addedInput schema / properties / x1 / description
      Added value: +"First extension line origin X coordinate in WCS"
    • addedInput schema / properties / x2 / description
      Added value: +"Second extension line origin X coordinate in WCS"
    • addedInput schema / properties / y1 / description
      Added value: +"First extension line origin Y coordinate in WCS"
    • addedInput schema / properties / y2 / description
      Added value: +"Second extension line origin Y coordinate in WCS"
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false, so the description carries most of the load and does add value: it discloses the side-effect (a DIMENSION entity is added) and the dependency on the active dimension style. It stops short of noting reversibility/undo or transactional requirements, which matters for a mutating drawing tool.

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?

Three short, labeled lines with the action front-loaded and no filler. Side-effects and disambiguation are broken out where the agent can find them immediately.

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?

An output schema exists, so return values need not be described, and the mutation plus style/layer defaults are covered. Minor gap: no note on how the created entity is identified or whether it participates in the active transaction.

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 schema already explains each coordinate as a WCS point. The description reinforces WCS and the active-style behavior but adds no syntax or constraint detail beyond the schema; baseline 3 applies.

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?

States a specific verb+resource ('Create an aligned dimension') and the exact inputs it consumes (WCS extension points plus a dimension-line point). The disambiguation line gestures at how it differs from other dimension tools, though it describes the geometric outcome rather than naming dimension_linear as the alternative.

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

Usage Guidelines3/5

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

Implies usage through 'using the active drawing's dimension style' and the layer default, but never says when to pick this over dimension_linear, dimension_angular, or dimension_ordinate. The agent must infer the choice from the geometry description alone.

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