multiCAD-mcp-server

Overview Schema Source Related Servers Discussions Admin

manage_blocks

Create, insert, inspect, and manage reusable CAD blocks and attribute tags in DWG/DXF drawings for doors, windows, symbols, and furniture.

Instructions

Create, insert, inspect, and manage reusable CAD blocks and attribute tags.

Behavior:

Mutation: Mutates drawing by adding block definitions (create), inserting block references (insert), or updating attribute tags (set_attrs). list, info, and get_attrs are read-only.
Persistence: Block definitions and inserted instances persist in the DWG/DXF database.
Side Effects: Auto-creates destination layer if nonexistent during insert.

Usage Guidelines:

When to Use: Call to insert reusable standard components (doors, windows, sanitaryware, electrical symbols, furniture), inspect block library definitions, or read/write block attribute tags (e.g. door width, fire rating).
Sibling Routing / Alternatives:
- For drawing primitive 2D geometry (lines, rectangles, polylines), use draw_entities.
- For transforming or deleting arbitrary entity instances, use manage_entities.
- For external project references linked as DWG files, use manage_xrefs.

Shorthand Grammar:

list: List all block definitions in drawing.
info|block_name|include: Get definition details and reference count (include: info, references, both).
insert|name|point|scale|rotation|layer|color: Insert block instance at point (e.g. insert|Door|10,20|1.5|90|walls|red).
create|name|handles|base_point|description: Create new block definition from existing entity handles.
get_attrs|handle: Query attribute key/value dictionary from a block reference handle.
set_attrs|handle|attributes_json: Set attribute values on a block reference handle (e.g. set_attrs|A1|{"TAG":"val"}).

Defaults: scale=1.0, rotation=0, layer=0, color=white.

Parameters:

operations: Shorthand string (one command per line) or JSON array of block operation objects.

Returns: JSON string containing per-operation execution results, block details, and inserted handles.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`operations`	Yes

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

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses mutation semantics per operation, flags which commands are read-only (list, info, get_attrs), states persistence in the DWG/DXF database, and reveals a side effect (auto-creating the destination layer on insert). Missing only permission/auth requirements and error-failure behavior, which keeps it short of a 5.

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?

Well front-loaded with Purpose, Behavior, Usage Guidelines, and Grammar headings, so an agent can stop reading early once it has what it needs. The grammar section is long but each line maps to a distinct operation, so little is padding; a slightly tighter parameter/default treatment would earn a 5.

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?

For a single-parameter dispatcher tool with an output schema, the description supplies everything needed to invoke it correctly: operation grammar, defaults, examples, side effects, and routing to alternatives. The return values are covered by the output schema, and the description only summarizes them, which is appropriate.

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 coverage is 0% and the single parameter is a freeform `operations` string, so the description must compensate and largely does: it documents the shorthand grammar command-by-command, enumerates valid values for `include`, lists defaults (scale=1.0, rotation=0, layer=0, color=white), and gives worked examples. Minor gap: the schema declares type string while the description also allows a JSON array form, and valid color/layer token syntax is only shown by example.

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?

States a specific verb set (create, insert, inspect, manage) against a specific resource (reusable CAD blocks and attribute tags), and explicitly names the sibling tools it should not be confused with (draw_entities, manage_entities, manage_xrefs). An agent can distinguish it from every listed sibling without opening a single 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?

Has a dedicated 'When to Use' section with concrete trigger scenarios (doors, windows, sanitaryware, symbols) and a Sibling Routing block that names three alternatives with the condition that selects each. Nothing about tool selection is left to inference.

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

Deploy Server