Skip to main content
Glama
Sign In
AutoCAD MCP Pro

AutoCAD MCP Pro

by U-C4N
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

P&ID: Instrument Index

pid_instrument_index

Extracts every P&ID instrument bubble with its ISA-5.1 tag reading and connected tags, handles, or signals from the drawing graph, optionally exporting rows to a CSV without modifying the drawing.

Instructions

Every instrument bubble with its ISA-5.1 reading and what it connects to.

Rows come from pid_graph, never from typed-in lists; the drawing is not modified. csv_path is the only file this tool writes (so it is not annotated read-only); it is validated before the drawing is read, and an empty path, a directory or a missing parent folder is refused. signal_lines counts ISA-5.1 signal lines only; connected_to names a tag, a handle, or the lines a junction on the instrument's line joins.

Input Schema

NameRequiredDescriptionDefault
scopeNocurrent_space | allcurrent_space
csv_pathNoWrite the rows as CSV here (inside ALLOWED_PATHS); text that starts like a formula (= + - @ tab CR) is prefixed with ' so a spreadsheet never runs it
toleranceNoEndpoint-to-port snap distance (mm)
label_searchNoHow far to look for tag/line-number text (mm)
include_foreignNoClassify INSERTs not placed by this server (confidence < 1)

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.7.0
    • changedInput schema / properties / csv_path / description
      Previous value: -"Write the rows as CSV here (inside ALLOWED_PATHS)"New value: +"Write the rows as CSV here (inside ALLOWED_PATHS); text that starts like a formula (= + - @ tab CR) is prefixed with ' so a spreadsheet never runs it"
    • addedInput schema / properties / include_foreign
      Added value: +{
+  "default": true,
+  "description": "Classify INSERTs not placed by this server (confidence < 1)",
+  "type": "boolean"
+}
    • addedInput schema / properties / label_search
      Added value: +{
+  "default": 15,
+  "description": "How far to look for tag/line-number text (mm)",
+  "exclusiveMinimum": 0,
+  "type": "number"
+}
  2. Addedv1.6.0

TDQS

A4.3/5.0
Behavior3/5

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

No annotations are given, so the description carries the full behavioral burden. It does well on write scope: `csv_path` is the only file touched, it is pre-validated, and empty paths, directories, or missing parents are refused — useful safety detail an agent can't infer elsewhere. However, output shape, row volume/pagination expectations for large drawings, and whether re-running overwrites an existing CSV are unstated.

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?

Roughly four tight sentences with no filler; the core deliverable is front-loaded and the constraint/safety details follow in descending priority. Every sentence adds a fact the reader would otherwise have to guess.

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 five-optional-parameter reporting tool with a full schema and an annotations block, the description covers the pieces structured fields don't: data provenance, no drawing mutation, the single file write and its validation rules, and how counts/connections are interpreted. The clauses on `signal_lines` and `connected_to` read as output-field semantics, which is mildly redundant with the output schema but not harmful.

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?

With 100% schema coverage the baseline is 3, and the description adds genuine meaning on top: `csv_path` gets the ALLOWED_PATHS constraint and formula-injection escaping behavior, which the schema only hints at. The numeric tuning parameters (`tolerance`, `label_search`) are left entirely to the schema, keeping it below a 5.

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 opening sentence names a specific deliverable (every instrument bubble with its ISA-5.1 reading and connections) and the provenance (rows come from `pid_graph`), which separates it from the sibling inventory tools `pid_line_list` and `pid_equipment_list` without ambiguity. An agent knows exactly what resource this yields.

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?

It makes clear the data is derived from the graph rather than typed-in lists and that the drawing itself is untouched, which frames when to reach for this tool. It stops short of explicitly naming alternatives (e.g., use `pid_line_list` for lines instead) or stating when not to use it.

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