Skip to main content
Glama
geongyeelee

autocad-mcp

by geongyeelee

draw_circle

Draw a circle in AutoCAD 2027 by specifying its center coordinates and radius; optionally assign a layer and ACI color.

Instructions

Draw a circle in AutoCAD 2027.

Args: center: [x, y] or [x, y, z] center coordinates. radius: Circle radius (> 0). layer: Optional layer name. color: Optional ACI color (1-255).

Input Schema

NameRequiredDescriptionDefault
colorNo
layerNo
centerYes
radiusYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations exist, so the description carries the full behavioral burden, yet it says nothing about side effects (a new entity is added to the current drawing), whether an active session/connection is required, or whether the operation is undoable. For a mutating tool this is a meaningful gap, partly offset by the presence of an output schema.

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?

One front-loaded purpose sentence followed by a compact args list; every line carries parameter information. The 'AutoCAD 2027' version tag is the only near-redundant element.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 all four parameters are covered. However, for a drawing-creation tool with zero annotations, the absence of any statement about connection requirements or the effect on the active drawing leaves an agent guessing about execution context.

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

Parameters4/5

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

Schema description coverage is 0%, and the description compensates well: it documents center as [x, y] or [x, y, z], radius as strictly positive, layer as optional, and color as an ACI index 1-255. The ACI range and coordinate formats are genuinely new information not present in the schema.

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 ('Draw a circle in AutoCAD 2027') that unambiguously separates it from draw_line, draw_arc, and draw_polyline by geometry type. It stops short of explicitly naming those alternatives, so it is clear but not fully differentiating.

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?

No guidance on when to use this versus sibling geometry tools, and no preconditions such as an active AutoCAD connection or which drawing the circle lands in. The agent must infer all routing decisions from the tool name alone.

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