Skip to main content
Glama
Sign In
AutoCAD MCP Pro

AutoCAD MCP Pro

by U-C4N
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

P&ID: Equipment List

pid_equipment_list

Extract equipment, valve, and connector nodes with their ports and connected line counts from a P&ID graph, optionally exporting the rows to CSV.

Instructions

Every equipment, valve and connector node with its ports and how many lines reach them.

Rows come from pid_graph; the drawing is not modified and csv_path is the only file this tool writes, validated before the drawing is read.

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

A3.9/5.0
Behavior4/5

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

Goes meaningfully beyond the annotations by clarifying that the drawing itself is not modified despite readOnlyHint=false, that `csv_path` is the sole file written, and that the path is validated before the drawing is read. The remaining gap is what happens when `csv_path` is null, which the description leaves unstated.

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?

Two tight sentences with the output content front-loaded and the side-effect caveats second. Slightly dense phrasing ('the only file this tool writes') but nothing is wasted.

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?

Return shape is covered by the output schema and all five parameters are documented in-schema, so the description's main remaining job is the write side-effect, which it handles. Only the no-CSV (in-memory) return path is left implicit.

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%, so scope, tolerance, label_search and include_foreign are already documented; the description adds only the validation-ordering nuance for `csv_path`. Baseline 3 applies since the schema carries the parameter burden.

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 extraction verb and resource: every equipment, valve and connector node with its ports and incoming line counts. It also names its data source (`pid_graph`), which separates it from sibling listing tools like pid_line_list and pid_instrument_index that cover different node classes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Saying rows come from `pid_graph` implies a prerequisite (build/read the graph first) but never states explicitly when to choose this over pid_line_list, pid_instrument_index, or pipe_takeoff. Usage is implied rather than prescribed, with no exclusions.

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