multiCAD-mcp-server

Overview Schema Source Related Servers Discussions Admin

manage_layers

Create, edit, toggle, restyle, and apply AECO layer templates in CAD drawings to organize structure, enforce standards, isolate geometry, and set lineweights.

Instructions

Create, modify, toggle visibility, restyle, and apply standardized AECO layer templates.

Behavior:

Mutation: Mutates drawing layer table (creates layers, renames, changes colors, sets lineweights).
Destructive Actions: Flag delete|name as destructive; removes target layer definition (layer cannot contain entities or be active layer 0).
Persistence: Layer definitions, visibility states, colors, and lineweights persist in DWG/DXF database.
Side Effects: Toggling layers (on/off) updates viewport entity visibility immediately.

Usage Guidelines:

When to Use: Call to organize drawing structure, enforce architectural CAD layer standards (template|aeco), isolate or hide geometry, set lineweights, or create target layers before drawing.
Sibling Routing / Alternatives:
- For creating geometry on specific layers, use draw_entities(entities="line|...|layer").
- For moving existing entities between layers, use manage_entities(operations="set_layer|...").
- For paperspace layout sheets and viewports, use manage_layouts.

Shorthand Grammar:

create|name|color|lineweight: Create new layer (e.g. create|walls|red|50).
delete|name: Delete empty layer (destructive).
rename|old|new: Rename existing layer.
on|names: Turn on layers (comma-separated, e.g. on|walls,doors).
off|names: Turn off layers (e.g. off|furniture).
set_color|name|color: Change layer color (e.g. set_color|walls|red).
template|preset: Batch-create standard layer palette (presets: aeco/cte, aia, mep).
is_on|name: Query if layer is currently visible.
list: List all layers in drawing.
info: Detailed layer summary with colors and states.

Defaults: color=white, lineweight=25 (0.25mm), template preset=aeco.

Parameters:

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

Returns: JSON string containing per-operation execution results, layer list, and status.

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.9/5.0

Behavior5/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 thoroughly: it discloses mutation of the layer table, destructive semantics for delete (including the constraint that the layer must be empty and not layer 0), persistence behavior in DWG/DXF, and the immediate viewport side effect of on/off toggling.

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?

Front-loaded with purpose, then cleanly sectioned into Behavior, Usage Guidelines, Grammar, Defaults, Parameters, and Returns. Every line is functional, though the grammar enumeration is lengthy and could be marginally tighter.

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 mutation tool with an output schema present, the description covers behavioral traits, destructive constraints, usage routing, accepted command syntax, and defaults. Return values are summarized and backed by the output schema, so no agent-critical information is missing.

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?

The single `operations` parameter has 0% schema coverage, yet the description fully compensates with a complete shorthand grammar (command|arg syntax per operation), a list of valid template presets, an alternative JSON array form, and documented defaults for color and lineweight.

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?

Opens with a specific multi-verb statement of scope ('Create, modify, toggle visibility, restyle, and apply standardized AECO layer templates') tied to the layer-table resource. An agent can immediately distinguish it from sibling tools like manage_entities and draw_entities.

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?

Explicit 'When to Use' section enumerates concrete triggers (organize drawing structure, enforce CAD standards, isolate geometry, create target layers). The 'Sibling Routing / Alternatives' block names three alternatives with the exact condition that selects each, leaving nothing 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