Skip to main content
Glama
CDT AutoCAD Provider

CDT AutoCAD Provider

entity_create_text

Creates a TEXT entity at a WCS insertion point with drawing-unit height, rotation in degrees, and optional layer/color, returning its identifier for labels, callouts, and notes.

Instructions

Create TEXT at a WCS insertion point with drawing-unit height and rotation in degrees, optionally on a layer/color, and return its identifier.

Side-effects: Adds TEXT entity to active space. Disambiguation: Use for labels, callouts, and notes.

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": {
      "text": "<text>",
      "x": "<x>",
      "y": "<y>"
    },
    "name": "entity_create_text"
  }
}

Input Schema

NameRequiredDescriptionDefault
xYesInsertion point X coordinate in WCS drawing units
yYesInsertion point Y coordinate in WCS drawing units
textYesText string content to display
colorNoAutoCAD Color Index (ACI 1-255). Uses ByLayer if omitted
layerNoTarget layer name. Uses active layer if omitted
heightNoText height in drawing units (default: 2.5)
rotationNoText rotation angle in degrees counter-clockwise (default: 0.0)

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.1.1
    • addedInput schema / properties / color / description
      Added value: +"AutoCAD Color Index (ACI 1-255). Uses ByLayer if omitted"
    • addedInput schema / properties / height / description
      Added value: +"Text height in drawing units (default: 2.5)"
    • addedInput schema / properties / layer / description
      Added value: +"Target layer name. Uses active layer if omitted"
    • addedInput schema / properties / rotation / description
      Added value: +"Text rotation angle in degrees counter-clockwise (default: 0.0)"
    • addedInput schema / properties / text / description
      Added value: +"Text string content to display"
    • addedInput schema / properties / x / description
      Added value: +"Insertion point X coordinate in WCS drawing units"
    • addedInput schema / properties / y / description
      Added value: +"Insertion point Y coordinate in WCS drawing units"
  2. First observedv0.1.0

TDQS

A4.2/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 must add the mutation profile — and it does: 'Side-effects: Adds TEXT entity to active space' tells the agent which space is modified and that state changes. 'Return its identifier' also sets expectations for follow-up calls. Missing are failure modes (non-existent layer, no open document) and whether the entity is undoable.

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 sentences, front-loaded with the action and geometry, then side-effects, then disambiguation. No filler and no repetition of schema defaults.

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?

With an output schema present, return values need no explanation, and the description covers the mutation side-effect and intended use cases. The remaining gap is preconditions — whether a document must be open and whether the target layer must already exist — which matters for a 7-parameter creation tool.

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% and every parameter is documented with units and defaults, so the schema does the heavy lifting. The description's mention of height in drawing units, rotation in degrees, and optional layer/color only restates what the schema already says, matching the baseline 3.

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 first sentence gives a specific verb (Create) and resource (TEXT entity) plus the exact geometric semantics: WCS insertion point, drawing-unit height, rotation in degrees. The Disambiguation line separates it from the sibling entity_create_* primitives and from annotation tools like dimension_linear, so an agent can route without opening a schema.

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?

'Use for labels, callouts, and notes' gives clear positive usage context, and 'optionally on a layer/color' implies baseline defaults. It stops short of explicit exclusions (e.g., use dimension_linear for measurements, batch_create_entities for bulk text), so it's strong but not fully routing.

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