Skip to main content
Glama
Sign In
CDT AutoCAD Provider

CDT AutoCAD Provider

by SlncTrZ
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

entity_create_polyline

Creates a 2D lightweight polyline from WCS XY points, with optional closed, layer, and color settings, and returns the new entity identifier for further drawing operations.

Instructions

Create a 2D lightweight polyline from WCS XY points in drawing units, optionally closed/layered/colored, and return the new object identifier.

Side-effects: Adds LWPOLYLINE entity to active space. Disambiguation: Use for continuous multi-segment paths, contours, or closed boundaries.

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": {
      "points": "<points>"
    },
    "name": "entity_create_polyline"
  }
}

Input Schema

NameRequiredDescriptionDefault
colorNoAutoCAD Color Index (ACI 1-255). Uses ByLayer if omitted
layerNoTarget layer name. Uses active layer if omitted
bulgesNoOptional list of bulge values for arc segments (bulge = tan(included_angle/4))
closedNoWhether to close polyline connecting last vertex back to first (default: False)
pointsYesList of [X, Y] vertex coordinates in WCS drawing units
widthsNoOptional list of [start_width, end_width] for each segment
elevationNoZ elevation of the 2D polyline plane (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 / bulges
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "number"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional list of bulge values for arc segments (bulge = tan(included_angle/4))"
+}
    • addedInput schema / properties / closed / description
      Added value: +"Whether to close polyline connecting last vertex back to first (default: False)"
    • addedInput schema / properties / color / description
      Added value: +"AutoCAD Color Index (ACI 1-255). Uses ByLayer if omitted"
    • addedInput schema / properties / elevation
      Added value: +{
+  "default": 0,
+  "description": "Z elevation of the 2D polyline plane (default: 0.0)",
+  "type": "number"
+}
    • addedInput schema / properties / layer / description
      Added value: +"Target layer name. Uses active layer if omitted"
    • addedInput schema / properties / points / description
      Added value: +"List of [X, Y] vertex coordinates in WCS drawing units"
    • addedInput schema / properties / widths
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "items": {
+          "type": "number"
+        },
+        "type": "array"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional list of [start_width, end_width] for each segment"
+}
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

With readOnlyHint=false the mutation nature is already declared, and the description correctly reinforces this by disclosing the side-effect (adds LWPOLYLINE to active space) and that an identifier is returned. It says nothing about whether a transaction must be open first, whether the call is undoable, or what happens if the layer name does not exist — meaningful gaps for a write tool in a toolset that has explicit transaction_begin/commit siblings.

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 lines, each earning its place: capability and return value first, then side-effects, then disambiguation. No redundancy or filler.

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-value detail is unnecessary, and annotations cover the safety profile. The description is nearly complete, but the omission of transaction/prerequisite behavior leaves a small gap for a mutating entity-creation tool that sits alongside explicit transaction controls.

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 all seven parameters (points, closed, layer, color, bulges, widths, elevation) are already documented with defaults. The description only echoes the closed/layered/colored subset and the WCS drawing-units convention, adding little beyond the schema; the baseline of 3 is appropriate.

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?

The description names a specific verb (Create) and resource (2D lightweight polyline) and constrains the input to WCS XY points in drawing units, plus the optional closed/layered/colored modifiers and the returned object identifier. It distinguishes itself implicitly from single-segment siblings like entity_create_line via the 'continuous multi-segment paths' phrasing, but never names the alternative explicitly.

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?

The Disambiguation line gives clear when-to-use guidance: continuous multi-segment paths, contours, closed boundaries. It stops short of stating when NOT to use it or naming the specific sibling (entity_create_line, entity_create_arc) an agent should pick for simpler geometry.

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