Skip to main content
Glama
Sign In
AutoCAD MCP Server

AutoCAD MCP Server

by C48H74
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

zoom_extents

Destructive

Fits the current AutoCAD view to all drawing objects after inserts or edits, so users can see the full result without changing the drawing.

Instructions

Enquadra a vista atual em todos os objetos do desenho (ZOOM Extents).

QUANDO USAR: depois de inserir/desenhar coisas, para o usuário enxergar o resultado. Não altera o desenho (não entra no histórico de desfazer). Exemplo: zoom_extents().

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "zoom_extents"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A3.8/5.0
Behavior1/5

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

The description explicitly asserts 'Não altera o desenho (não entra no histórico de desfazer)' — a non-mutating, non-destructive view operation — while the annotations declare destructiveHint=true and readOnlyHint=false. These directly contradict, so per the rubric this scores 1 and is flagged.

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 blocks: what it does, when to use it, side-effect note, plus a call example. Every sentence carries information and nothing is padded.

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, so return-value explanation is unnecessary. For a zero-parameter view tool the description covers purpose, trigger and side effects adequately; the only shortfall is the unresolved conflict with the annotations rather than missing content.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The example call 'zoom_extents()' usefully confirms the empty-argument invocation.

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 — 'Enquadra a vista atual em todos os objetos do desenho' — with the canonical English term '(ZOOM Extents)' as a parenthetical anchor. An agent can immediately tell this is a viewport-fitting operation, distinct from the draw_* / dxf_* mutation siblings.

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?

'QUANDO USAR: depois de inserir/desenhar coisas, para o usuário enxergar o resultado' gives an explicit trigger condition tied to sibling tools (draw/insert). It stops short of 5 because it names no alternative (e.g. zoom-to-window/selection) or when-not case.

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