Skip to main content
Glama
Sign In
AutoCAD MCP Pro

AutoCAD MCP Pro

by U-C4N
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

P&ID: Line List

pid_line_list

Lists every P&ID line with number, class, size, service, spec, insulation, and endpoints, and can export the rows to CSV without changing the drawing.

Instructions

Every P&ID line with its number, class, size/service/spec/insulation and endpoints.

Rows come from pid_graph; untagged lines sort last with line_number: null. An end names a node's tag (its handle when untagged) and port, or — at a junction — the line numbers (or handles) of the lines it joins. The drawing is not modified; 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 beyond the annotations (readOnlyHint=false, destructiveHint=false) by pinning down the only side effect: the drawing is never modified and csv_path is the sole file written, validated before the drawing is read. Also discloses ordering and null-tag behavior (untagged lines sort last with line_number: null). Minor gaps remain (overwrite behavior of an existing CSV, failure modes), so not a 5.

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?

Four compact sentences, front-loaded with the returned content before row semantics and side-effect disclosure. Dense but every sentence carries information; no filler or restatement of the title.

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?

With an output schema present, return values need not be re-explained, yet the description supplies the semantic model an agent needs to interpret rows (tag-or-handle endpoints, junction rows joining lines, null line numbers). Complete for selection and invocation; only the CSV write edge cases are 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 description coverage is 100%, so the schema already explains scope, csv_path, tolerance, label_search and include_foreign. The description adds conceptual meaning to 'end' and junction rows but does not further explain any individual parameter, which is the expected baseline when the schema carries the load.

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?

Opens with a specific verb+resource (list every P&ID line) and enumerates exactly which attributes are returned (number, class, size/service/spec/insulation, endpoints). This clearly separates it from the other pid_* listing tools such as pid_equipment_list and pid_instrument_index.

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?

Usage is implied by the name and the first line, and pid_graph is named as the data source, but there is no explicit 'use this when... / use pid_graph or pid_instrument_index instead when...' guidance. The agent must infer when a line list is the right artifact versus the graph or the other indexes.

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