Skip to main content
Glama
trajis-tech

cad-eye-mcp

Official
by trajis-tech

cad_command

Run any of 400+ AutoCAD-style CADCraft commands for drawing inquiries not covered by other tools; changes stay in the viewer session and are never saved.

Instructions

Run a CADCraft command directly (its catalog has 400+ AutoCAD-style commands). Use for inquiries the other tools do not cover. Changes stay in the viewer session and are never saved; saving, exporting and opening files is blocked.

Input Schema

NameRequiredDescriptionDefault
paramsNoJSON parameters of the command
commandYesCADCraft command id, e.g. list, dist, area, id, massprop, count, layiso, draworder

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4/5.0
Behavior4/5

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

With annotations already declaring readOnlyHint=false, destructiveHint=false, the description usefully clarifies why: mutations happen only in the viewer session and are never persisted, and save/export/open are blocked. That closes the apparent tension between 'changes things' and 'non-destructive'. It omits return format and error behavior for unknown command ids.

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, front-loaded with what it does, then when to use it, then the persistence constraint. No filler and nothing important buried.

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?

Safety and persistence semantics are fully covered, and both parameters are explained by the schema, so an agent can call this correctly. The one real gap is discovery: it advertises 400+ commands but offers no way to learn which ids exist or what `params` each expects.

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%: `command` is documented with eight concrete example ids and `params` is typed as a free-form JSON object. The description adds only the scale of the catalog and no guidance on how per-command parameter shapes relate to the `params` blob, so the baseline of 3 applies.

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 concrete verb and resource ('Run a CADCraft command directly') and quantifies the surface area (400+ AutoCAD-style commands), so the agent knows this is an arbitrary-command dispatcher. It signals itself as a catch-all fallback but never names a specific sibling (measure, find, layers) it supersedes, which keeps it short of a 5.

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?

'Use for inquiries the other tools do not cover' gives a clear selection rule: try the specialized siblings first, fall back here. It stops short of explicit exclusions or naming which sibling handles which category, leaving the agent to infer the mapping from sibling names alone.

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