Skip to main content
Glama
CDT AutoCAD Provider

CDT AutoCAD Provider

view_screenshot

Read-only

Capture the live AutoCAD application window as PNG bytes for quick visual verification; use PDF export for vector deliverables.

Instructions

Capture the live AutoCAD application window as PNG bytes; this is read-only and requires the live COM screenshot capability.

Side-effects: None. Returns raster PNG bytes. Disambiguation: Quick visual verification; use document_export_pdf for vector deliverables.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

The annotations already declare readOnlyHint=true, and the description reinforces that with "this is read-only" plus "Side-effects: None." It adds useful behavioral context by stating the return type is "raster PNG bytes" and noting the live COM screenshot capability requirement, though it does not discuss failure modes or whether the AutoCAD window must be visible.

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?

The description is compact and front-loaded with the core action, return format, side-effect profile, and sibling disambiguation. Every phrase carries useful selection or invocation information, with no redundant restatement of the title or schema.

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 zero-parameter, read-only screenshot tool with no output schema, the description covers what it does, what it returns, its side-effect profile, its precondition, and when to use a different export tool. Nothing essential for correct invocation is missing.

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 has zero parameters, so there are no parameter semantics to explain. The description correctly does not waste space discussing nonexistent inputs, and the schema is empty with additionalProperties false.

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 description uses a specific verb and resource: "Capture the live AutoCAD application window as PNG bytes." It also distinguishes the tool from the sibling document_export_pdf by clarifying that this produces raster PNG output for quick visual verification rather than vector deliverables.

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?

It explicitly frames the intended use as "Quick visual verification" and names the alternative: "use document_export_pdf for vector deliverables." This gives the agent a clear condition for choosing this tool versus a sibling without needing to inspect other definitions.

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