Skip to main content
Glama
Sign In
CAD MCP Server

CAD MCP Server

by 652036
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

add_radius_dimension

Adds a radius dimension to an arc in a CAD drawing, using the arc ID and leader point to place the measurement annotation.

Instructions

Add a radius dimension.

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": {
      "arc_id": "<arc_id>",
      "leader_point": "<leader_point>"
    },
    "name": "add_radius_dimension"
  }
}

Input Schema

NameRequiredDescriptionDefault
arc_idYes
leader_pointYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

D1.5/5.0
Behavior1/5

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

No annotations are provided, so the description carries the full disclosure burden, and it discloses nothing. It does not say whether this mutates the drawing, whether the arc must already exist and be committed, whether the operation is undoable, or how leader_point affects placement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single five-word sentence is not concise so much as under-specified; it is front-loaded only because there is nothing else to front-load.

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

Completeness1/5

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

For a mutation tool with a nested-object parameter, no annotations, no output schema, and zero parameter documentation, the definition is completely inadequate. An agent cannot reliably construct a correct call from this description.

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

Parameters1/5

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

Two required parameters with 0% schema description coverage, including a nested leader_point object with x/y. The description mentions neither arc_id nor leader_point, so the agent gets no explanation of what the arc reference is or how the leader point is interpreted. Full compensation was required and none was given.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is a verbatim prose restatement of the tool name 'add_radius_dimension' — there is no information beyond what the identifier already encodes. It also fails to distinguish this tool from near-identical siblings such as add_dimension_radial and add_diameter_dimension that appear in the same toolset.

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 when-to-use guidance, no prerequisites, and no mention of the sibling dimension tools an agent would have to choose between. The only hint of usage is inferable from the name itself.

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