CDT AutoCAD Provider

Overview Schema Source Related Servers Discussions Admin

viewport_create

Creates a paper-space viewport on a specified layout with defined center, size, model-space view target, and scale for drawing presentation.

Instructions

Create a paper-space viewport on a named layout with center/size in paper units, WCS view target, and positive custom scale.

Side-effects: Adds VIEWPORT entity to active layout. Disambiguation: Requires active paper-space layout.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "layout": "<layout>",
      "center_x": "<center_x>",
      "center_y": "<center_y>",
      "width": "<width>",
      "height": "<height>",
      "view_center_x": "<view_center_x>",
      "view_center_y": "<view_center_y>"
    },
    "name": "viewport_create"
  }
}

Input Schema

Name	Required	Description
`scale`	No	Viewport scale factor (e.g. 0.02 for 1:50 scale) (default: 1.0)
`width`	Yes	Viewport width in paper units (mm or inches)
`height`	Yes	Viewport height in paper units (mm or inches)
`layout`	Yes	Name of paper-space layout to place the viewport on
`center_x`	Yes	Viewport center X coordinate on paper sheet in paper units
`center_y`	Yes	Viewport center Y coordinate on paper sheet in paper units
`view_center_x`	Yes	Target model-space center X visible in viewport
`view_center_y`	Yes	Target model-space center Y visible in viewport

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.1.1Oct 24, 2026

addedInput schema / properties / center_x / description

Added value: +"Viewport center X coordinate on paper sheet in paper units"

addedInput schema / properties / center_y / description

Added value: +"Viewport center Y coordinate on paper sheet in paper units"

addedInput schema / properties / height / description

Added value: +"Viewport height in paper units (mm or inches)"

addedInput schema / properties / layout / description

Added value: +"Name of paper-space layout to place the viewport on"

addedInput schema / properties / scale / description

Added value: +"Viewport scale factor (e.g. 0.02 for 1:50 scale) (default: 1.0)"

addedInput schema / properties / view_center_x / description

Added value: +"Target model-space center X visible in viewport"

addedInput schema / properties / view_center_y / description

Added value: +"Target model-space center Y visible in viewport"

addedInput schema / properties / width / description

Added value: +"Viewport width in paper units (mm or inches)"

First observedv0.1.0Sep 9, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false; the description adds the concrete side effect ('Adds VIEWPORT entity to active layout'), which is exactly the kind of context annotation does not carry. It stops short of covering rollback/undo interaction or failure behavior when the layout is missing, so not 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, front-loaded lines: purpose first, then side effects, then disambiguation. Every sentence carries distinct information with no filler.

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?

For an 8-parameter mutation tool with an output schema and only a readOnlyHint annotation, the description covers purpose, side effect, and the key precondition. Remaining gaps — behavior when the named layout does not exist, and whether a transaction is required — are minor but real.

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 100%, so the baseline is 3; the description earns one more by stating a semantic constraint the schema omits — the scale must be positive — and by framing width/height as paper units and view_center as a WCS target. It adds meaning rather than repeating the schema.

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 and resource ('Create a paper-space viewport on a named layout') and enumerates the defining inputs (center/size in paper units, WCS view target, positive custom scale). This clearly separates it from sibling mutators like viewport_set_scale, viewport_lock, and viewport_delete, which operate on existing viewports.

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?

The 'Disambiguation' line gives a real precondition — an active paper-space layout is required — which tells the agent when the call is valid. It does not name alternatives (e.g. viewport_set_scale for existing viewports) or explicit when-not conditions, so it falls short of a 5.

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

Deploy Server