multiCAD-mcp-server

Overview Schema Source Related Servers Discussions Admin

inspect_drawing

Queries read-only spatial data from CAD or DXF models, returning drawing extents, room schedules, point containment, geometric intersections, and nearest object snaps.

Instructions

Inspect spatial intelligence, dimensions, geometric intersections, and object snaps.

Behavior:

Mutation: Strictly read-only; does not modify drawing entities, layers, or CAD state.
Persistence: No persistent side effects or disk modifications.
Side Effects: Computes spatial relationships in-memory from active CAD or DXF model.

Usage Guidelines:

When to Use: Call whenever the AI needs spatial intelligence (drawing extents, room schedules, what entity is located at coordinate X,Y, line crossings, or nearest snap points).
Sibling Routing / Alternatives:
- For launching an interactive graphical web viewer for human visual inspection, use show_drawing_viewer.
- For computing area or measuring specific entity handles, use manage_entities(operations="area|...").
- For requesting interactive human mouse clicks in the CAD viewport, use prompt_user.

Modes & Parameters:

mode: Inspection mode ("summary", "point", "intersections", "snap"). Default: "summary".
- "summary": Global bounding box, room schedule, layer inventory, and ASCII minimap.
- "point": Point-in-polygon raycasting query ("what room/space contains point X,Y?"). Requires point="x,y".
- "intersections": Detect geometric crossings between entities. Optional: handle1, handle2, layer.
- "snap": Object snap assistant. Finds closest endpoint, midpoint, or center to point. Requires point="x,y".
point: Coordinates "x,y" or "x,y,z" (required for "point" and "snap" modes).
handle1: Optional first entity handle to restrict intersection checks.
handle2: Optional second entity handle to test intersection against handle1.
snap_types: Comma-separated snap filters: "endpoint", "midpoint", "center". Default: "endpoint,midpoint,center".
tolerance: Search radius for snap points in drawing units. Default: 1.5.
layer: Optional layer name to filter intersection candidates.

Returns: JSON string with mode-specific spatial data, coordinates, and matched entities.

Input Schema

TableJSON Schema

Name	Required	Default
`mode`	No	summary
`layer`	No
`point`	No
`handle1`	No
`handle2`	No
`tolerance`	No
`snap_types`	No	endpoint,midpoint,center

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 20, 2026

TDQS

A5/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full behavioral burden. It explicitly declares that the operation is strictly read-only, has no persistent side effects, and computes spatial relationships in-memory from the active CAD or DXF model, covering the key safety and side-effect concerns for a mutation-capable-looking tool.

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?

The description is appropriately sized for a tool with seven parameters and four distinct modes. It is front-loaded with purpose, then behavior, usage, modes, and returns, with no redundant filler; each section earns its place.

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

Completeness5/5

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

Given the 0% schema coverage, no annotations, and an output schema already present, the description supplies everything the agent needs: mode routing, parameter meaning, behavioral guarantees, and usage alternatives. It does not need to describe return values because an output schema exists.

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?

Schema description coverage is 0%, so the description must compensate fully, and it does. It explains every parameter in context: allowed mode values and their specific behaviors, required point format for point/snap modes, optional handle filters, snap_types values, tolerance semantics, and layer filtering.

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

Purpose5/5

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

The description states a specific verb (inspect) and enumerates the concrete resources it operates on: spatial dimensions, geometric intersections, and object snaps. It clearly distinguishes this tool from siblings through explicit routing guidance, so an agent can identify it without opening the schema.

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

Usage Guidelines5/5

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

It provides an explicit 'When to Use' section and directly names alternatives such as show_drawing_viewer, manage_entities, and prompt_user, with the condition that selects each. This fully answers when to use this tool versus its siblings.

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

Deploy Server