Skip to main content
Glama
puran-water

AutoCAD LT AutoLISP MCP Server

by puran-water

entity

Create, query, and modify AutoCAD LT drawing entities like lines, circles, and text to build and edit engineering drawings programmatically.

Instructions

Entity creation, querying, and modification.

Create operations: create_line — x1, y1, x2, y2, layer? create_circle — data: {cx, cy, radius}, layer? create_polyline — points: [[x,y],...], data: {closed?}, layer? create_rectangle — x1, y1, x2, y2, layer? create_arc — data: {cx, cy, radius, start_angle, end_angle}, layer? create_ellipse — data: {cx, cy, major_x, major_y, ratio}, layer? create_mtext — data: {x, y, width, text, height?}, layer? create_hatch — entity_id, data: {pattern?}

Read operations: list — layer? → list entities count — layer? → count entities get — entity_id → entity details

Modify operations: copy — entity_id, data: {dx, dy} move — entity_id, data: {dx, dy} rotate — entity_id, data: {cx, cy, angle} scale — entity_id, data: {cx, cy, factor} mirror — entity_id, x1, y1, x2, y2 offset — entity_id, data: {distance} array — entity_id, data: {rows, cols, row_dist, col_dist} fillet — data: {id1, id2, radius} chamfer — data: {id1, id2, dist1, dist2} erase — entity_id

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
operationYes
x1No
y1No
x2No
y2No
pointsNo
layerNo
entity_idNo
dataNo
include_screenshotNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior3/5

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

Annotations provide readOnlyHint=false, correctly indicating this is a mutation tool. The description adds significant behavioral context by detailing 19 specific operations with their parameter patterns, which goes beyond the annotations. However, it doesn't disclose important behavioral traits like error conditions, permission requirements, whether operations are destructive (beyond 'erase'), or how modifications affect the drawing state.

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?

The description is efficiently structured with clear operation categories (Create/Read/Modify) and bullet-like syntax for each operation. Every line adds value by specifying operation-parameter mappings. While somewhat dense due to the many operations, there's minimal waste—each operation specification serves a clear documentation purpose.

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?

Given the tool's complexity (19 operations across 3 categories), 0% schema coverage, and the presence of an output schema (which handles return values), the description provides substantial operational context. It documents parameter requirements for each operation type, which is crucial given the schema's lack of descriptions. The main gap is the absence of behavioral constraints and sibling tool differentiation.

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?

With 0% schema description coverage and 10 parameters, the description carries the full burden of parameter documentation. It excels by mapping each operation to specific parameter requirements (e.g., 'create_line — x1, y1, x2, y2, layer?'), providing clear semantic meaning that the schema's generic property names completely lack. The description effectively compensates for the schema's deficiencies.

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 clearly states this tool handles 'Entity creation, querying, and modification' which is a specific verb+resource combination. It distinguishes itself from siblings like 'layer', 'block', or 'drawing' by focusing specifically on geometric entities rather than layers, blocks, or drawing properties. However, it doesn't explicitly contrast with these alternatives in the description text itself.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus its siblings (annotation, block, drawing, layer, pid, system, view). It lists operations but doesn't explain prerequisites, when certain operations are appropriate, or what distinguishes entity operations from other CAD manipulation tools. The user must infer usage from the operation list alone.

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/puran-water/autocad-mcp'

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