multiCAD-mcp-server

Overview Schema Source Related Servers Discussions Admin

manage_layouts

Create, activate, list, and delete AutoCAD paperspace layouts; add scaled viewports and AECO title blocks for presentation sheets.

Instructions

Manage AutoCAD paperspace layouts, presentation sheets, viewports, and AECO title blocks.

Behavior:

Mutation: Mutates paperspace configurations, layout dictionaries, and sheet entities.
Destructive Actions: Flag action="delete" as DESTRUCTIVE; permanently removes target layout sheet and all entities/viewports placed upon it. Cannot delete active layout or "Model" tab.
Persistence: Layout definitions and viewport scales persist in drawing database upon save.
Side Effects: Switches active tab in CAD interface when action="activate" or action="create" is called.

Usage Guidelines:

When to Use: Call to compose architectural presentation sheets, configure standard paper formats (A4-A0), insert scaled modelspace viewports, add standardized title blocks, or switch active sheets.
Sibling Routing / Alternatives:
- For adjusting camera zoom, pan, or visual style inside active modelspace viewport, use manage_view.
- For exporting or plotting finished sheet to vector PDF document, use export_data(format="pdf").
- For creating 2D/3D geometry in modelspace, use draw_entities.

Actions & Per-Action Required Parameters:

"create": Create new layout sheet with border frame, viewport, and title block.
- Required: name, paper_size, orientation, scale.
"list": List all layouts in drawing with active status.
- Required: (none).
"activate": Switch active CAD workspace tab to this layout.
- Required: name.
"delete": (DESTRUCTIVE) Permanently delete named layout sheet.
- Required: name (cannot delete active layout or "Model").
"add_viewport": Add architectural viewport to existing layout.
- Required: name, scale. Optional: model_center, viewport_rect.
"add_titleblock": Add AECO standard title block with metadata.
- Required: name, title, author, sheet_number.

Parameters:

action: Action to perform ("create", "list", "activate", "delete", "add_viewport", "add_titleblock"). Default: "create".
name: Layout sheet name (e.g. "Plano_01_Distribucion").
paper_size: Paper standard ("A4", "A3", "A2", "A1", "A0", "LETTER", "TABLOID"). Default: "A3".
orientation: Sheet orientation ("landscape", "portrait"). Default: "landscape".
scale: Architectural scale ("1:50", "1:100", "1:20", "1:200", "1:500", "1:10", "1:1"). Default: "1:50".
model_center: Center coordinate in modelspace to focus ("x,y", e.g. "15.0, 10.0").
viewport_rect: Viewport center and dimensions in paper mm ("cx,cy,w,h", e.g. "210,148,380,260").
title: Project or sheet title for title block.
author: Designer, collegiate engineer, or author name.
date: Date string for title block.
sheet_number: Sheet index or code (e.g. "PL-01", "1/4"). Default: "1/1".
unit: Model units ("m" for meters, "mm" for millimeters). Default: "m".

Returns: JSON string with action result, layout details, and success status.

Input Schema

TableJSON Schema

Name	Required	Default
`date`	No
`name`	No
`unit`	No	m
`scale`	No	1:50
`title`	No
`action`	No	create
`author`	No
`paper_size`	No	A3
`orientation`	No	landscape
`model_center`	No
`sheet_number`	No	1/1
`viewport_rect`	No

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 provided, the description carries the full burden and does so: it discloses mutation scope, marks action="delete" as destructive with the exact blast radius (all entities/viewports) and its guard rails (cannot delete active layout or Model tab), notes persistence on save, and warns about the active-tab UI side effect. Only permission prerequisites and failure modes (e.g. duplicate name) are unstated, which is minor.

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 and organized under Behavior / Usage / Actions / Parameters headings, with the destructive warning surfaced early. It is long, and the per-action required-parameter list partly restates information in the Parameters section, but most of the length is warranted by 12 undocumented parameters.

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 12-parameter multi-action mutation tool with no annotations and 0% schema coverage, the description supplies everything needed: action enumeration, per-action required params, defaults, formats, destructive semantics, and side effects. An output schema exists, so the brief Returns line is sufficient.

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% across 12 parameters, so the description must compensate entirely, and it does: every parameter gets meaning, allowed values, defaults, and concrete format examples (e.g. "x,y", "cx,cy,w,h", "PL-01"). The per-action required/optional mapping is additional value the schema does not express.

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 first line names a specific resource domain (paperspace layouts, presentation sheets, viewports, AECO title blocks) and the per-action breakdown pins down each operation precisely. It is clearly distinguishable from siblings like manage_view, draw_entities, and export_data, which it explicitly names.

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?

The Usage Guidelines section states when to call it (compose sheets, configure paper formats, insert viewports, add title blocks, switch sheets) and provides explicit sibling routing with conditions for three alternatives. Nothing 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