AutoCAD MCP

autocad_connection_status

Read-onlyIdempotent

Check live AutoCAD reachability and active backend before drawing to confirm you are drawing in a live session, not the headless ezdxf fallback.

Instructions

Report which backend is active and whether live AutoCAD is reachable.

Never launches AutoCAD — it only checks whether a running instance can be attached to. Use this before drawing to confirm you are actually about to draw inside live AutoCAD rather than the headless ezdxf fallback.

Returns: str: JSON {"active_backend": "com"|"ezdxf", "platform", "pywin32_available", "live_autocad_reachable", "backend_selection_mode": "auto"|"ezdxf"|"com"}.

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": "autocad_connection_status"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 16, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: "Never launches AutoCAD — it only checks whether a running instance can be attached to," which prevents an agent from assuming this call spins up a session, plus the backend_selection_mode values that explain how the backend was chosen.

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?

The purpose and the critical non-launching constraint are front-loaded in two tight sentences, with the usage condition directly after. The Returns block largely restates the output schema, which is slightly redundant, but it is well structured and not bloated.

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?

Given a zero-parameter, read-only diagnostic with annotations covering safety and an output schema present, the description supplies everything needed: what it does, what it will not do (launch AutoCAD), and when to call it. No gaps remain for correct invocation.

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 no parameter semantics to document and the baseline is 4. Nothing in the description misleads about inputs.

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 diagnostic verb and resource: reporting the active backend and whether live AutoCAD is reachable. This is clearly distinguishable from the many action siblings (create_line, save_document, etc.) because it is framed as a status check rather than a mutation or query of drawing content.

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?

"Use this before drawing to confirm you are actually about to draw inside live AutoCAD rather than the headless ezdxf fallback" gives a concrete when-to-use condition tied to the drawing workflow. It doesn't name an alternative tool or a when-not-to-use case, but no sibling provides overlapping diagnostics, so the guidance is effectively complete.

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

Deploy Server