Skip to main content
Glama
Sign In
CDT AutoCAD Provider

CDT AutoCAD Provider

by SlncTrZ
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

object_get

Read-only

Retrieve a single CAD entity by backend ID or handle to inspect normalized type, layer, color, visibility, geometry, and space metadata. Use for read-only entity inspection.

Instructions

Read one object by backend object identifier and return normalized type, layer, color, visibility, geometry properties, and current-space metadata.

Side-effects: None. Read-only entity query. Disambiguation: Use for single entity inspection; use object_measure for calculated metrics.

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": {
      "object_id": "<object_id>"
    },
    "name": "object_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
object_idYesBackend entity identifier or persistent CAD handle

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.1
    • addedInput schema / properties / object_id / description
      Added value: +"Backend entity identifier or persistent CAD handle"
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

The description restates readOnlyHint=true with 'Side-effects: None. Read-only entity query.', which is duplicative of structured data rather than additive. It does not cover failure behavior (e.g., what happens with an unknown or stale handle) or permission requirements. With annotations covering the safety profile and an output schema present, a 3 is appropriate.

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?

Four short lines, front-loaded with the core action and return payload, then side-effects, then routing. No sentence is filler and structure is easy to scan.

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 a single-parameter read tool with annotations and an output schema, the description covers purpose, safety, and routing. The only gap is failing to differentiate from object_list/object_query, which matters given the dense object_* sibling group.

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 coverage is 100% and the sole parameter's description ('Backend entity identifier or persistent CAD handle') matches the description's phrasing, so the description adds no meaning beyond the schema. Baseline 3 applies.

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 ('Read one object by backend object identifier') and enumerates exactly what is returned (type, layer, color, visibility, geometry, space metadata). This lets an agent distinguish it from the write-side object tools without opening the schema.

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 an explicit condition and alternative: single entity inspection here, calculated metrics via object_measure. However, it omits the more immediate lookalikes in the sibling set — object_list and object_query — leaving the agent to infer why it should pick object_get over those.

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