Skip to main content
Glama
Sign In
CDT AutoCAD Provider

CDT AutoCAD Provider

by SlncTrZ
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

view_zoom_window

Zooms the live AutoCAD view to specified WCS XY window bounds, rejecting zero-area windows while leaving drawing geometry unchanged. Use it to focus the display on a precise rectangular area.

Instructions

Zoom the live AutoCAD view to the supplied WCS XY window bounds; zero-area windows are refused and drawing geometry is unchanged.

Side-effects: Changes display window; drawing geometry unmodified. Disambiguation: Zooms to specific bounding area.

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": {
      "x1": "<x1>",
      "y1": "<y1>",
      "x2": "<x2>",
      "y2": "<y2>"
    },
    "name": "view_zoom_window"
  }
}

Input Schema

NameRequiredDescriptionDefault
x1YesLower-left corner X coordinate in WCS
x2YesUpper-right corner X coordinate in WCS
y1YesLower-left corner Y coordinate in WCS
y2YesUpper-right corner Y coordinate in WCS

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.1
    • addedInput schema / properties / x1 / description
      Added value: +"Lower-left corner X coordinate in WCS"
    • addedInput schema / properties / x2 / description
      Added value: +"Upper-right corner X coordinate in WCS"
    • addedInput schema / properties / y1 / description
      Added value: +"Lower-left corner Y coordinate in WCS"
    • addedInput schema / properties / y2 / description
      Added value: +"Upper-right corner Y coordinate in WCS"
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations only give readOnlyHint=false, so the description usefully clarifies that the mutation is limited to the display window and that drawing geometry is untouched, plus the zero-area rejection rule. It is consistent with the annotation (view state does change), though it does not say whether the zoom is undoable or how it interacts with active viewports.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Front-loaded and short overall, but two of the four lines do not earn their place: "drawing geometry is unchanged" is restated as "Side-effects: ... drawing geometry unmodified," and the Disambiguation line merely repeats the first sentence rather than contrasting a sibling.

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?

An output schema exists, all four parameters are documented, and the description covers the side effect and the invalid-input rule, which is sufficient for a low-complexity view tool. The only real gap is routing against the extents-based sibling, which overlaps with usage guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each of x1/y1/x2/y2 already documented as WCS corners, so the baseline is 3. The description adds the useful constraint that a zero-area window is refused, which tells the agent the corners must define a non-degenerate rectangle.

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

Purpose4/5

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

States a specific verb and resource ("Zoom the live AutoCAD view") plus the exact scope ("supplied WCS XY window bounds"), which is enough to tell it apart from view_zoom_extents in practice. The sibling is never named, so the differentiation is inferred rather than explicit.

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

Usage Guidelines3/5

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

"Zooms to specific bounding area" and "supplied WCS XY window bounds" imply the use case (a caller-chosen rectangle rather than drawing extents), but the description never names view_zoom_extents as the alternative or states when each should be chosen. Usage must be inferred from the sibling list.

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

Deploy Server

Other Tools