Skip to main content
Glama
Sign In
CAD MCP Server

CAD MCP Server

by 652036
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

create_polyline

Draw a polyline through a series of X/Y points in a CAD drawing, optionally closing the shape and setting the unit for geometry and SVG previews.

Instructions

Create a polyline. If closed is true, stroke is closed in SVG preview. Points use unit (default mm).

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>",
      "closed": "<closed>"
    },
    "name": "create_polyline"
  }
}

Input Schema

NameRequiredDescriptionDefault
unitNo
layerNo
closedYes
pointsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It adds one useful behavioral detail—closed affects the SVG preview stroke—and specifies the default unit, but it omits side effects, layer behavior, permissions, and whether the polyline is created in modelspace or the current coordinate system.

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 are front-loaded with the action and contain no filler. Each sentence carries information, and the most important creation statement comes first.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and 0% schema description coverage, the description is too sparse for a create operation with four parameters. It does not say what layer is used, how points are connected, what happens when closed is false, or what the tool actually returns.

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 0%, so the description must compensate. It adds meaning for unit by giving a default of mm and ties points to that unit, and explains closed's SVG effect, but it does not explain the points array structure or the layer parameter, leaving clear gaps.

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 'Create' and resource 'polyline', so the core purpose is clear. However, among many sibling creation tools such as create_polygon, create_line, and create_spline, it does not differentiate when a polyline is the correct choice, so it stops short of 5.

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 gives no when-to-use guidance, no prerequisites, and no alternatives. It only states what the tool creates and a small behavior of the closed flag, leaving the agent to infer usage from the name and sibling list.

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