Skip to main content
Glama
AutoCAD MCP Pro
by U-C4N

P&ID: Connectivity Graph

pid_graph
Read-only

Extracts P&ID connectivity from AutoCAD drawings, resolving symbols, ports, lines, junctions and dangling endpoints with confidence scores so you can verify graph structure before trusting it.

Instructions

Connectivity of the drawing as it is, not as it was drawn.

Nodes: symbol INSERTs classified by catalogue name (confidence 1.0), ACADMCP_PID payload (0.95), tag attributes / block-name keywords (0.6) or a line touching an unknown INSERT (0.3); every node reports its source. Ports come from the INSERT's real rotation, scale and mirror, measured (a stretched bubble drops the node to 0.6 with a note). Edges: lines and polylines; each end resolves to a port, a junction on another line, or dangling with the nearest port as a hint — always within its own space, so scope="all" never joins two sheets. stats.confidence_min is the number to read before trusting a foreign drawing.

Returns nodes, edges, junctions, dangling, unclassified, offpage_links, stats, tolerance, scope and backend:

  • node: id, kind, block_name, family, symbol, tag, tag_parsed, tag_source, x, y, rotation_deg, scale, y_scale, mirrored, layer, space, description (its DESC attribute), source, confidence, notes, and ports {name, x, y, direction_deg, kind, radius, inferred, edges};

  • edge: id, line_class, class_source, line_number, number_source, size, service, spec, insulation, from, to, length (plus length_approximate when the engine measured none), layer, space, source; vertices and bulges with include_geometry;

  • junction: id, x, y, edges, space; dangling: edge, end, x, y, nearest.

Input Schema

NameRequiredDescriptionDefault
scopeNocurrent_space | all (every layout, current restored afterwards)current_space
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)
include_geometryNoInclude edge vertices

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A3.9/5.0
Behavior5/5

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

With readOnlyHint already given, the description adds substantial behavior: how nodes are classified with confidence values and a source tag, how rotation/scale/mirror are measured and degraded (stretched bubble drops to 0.6 with a note), how edge endpoints resolve to ports, junctions or dangling with a nearest-port hint, and that scope='all' never joins two sheets. That is exactly the inference an agent would otherwise have to guess.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The framing sentence and confidence narrative are front-loaded and earn their place, but the long per-field enumeration of node/edge/junction/dangling attributes largely duplicates the output schema that already exists, adding bulk rather than value.

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 read-only, five-parameter analysis tool with an output schema, the description covers input semantics, classification confidence and degraded cases well. The gap is selection guidance against sibling P&ID tools and any note on cost/scale of a full-model graph traversal.

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?

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning: ports come from real rotation/scale/mirror, resolution happens within tolerance, edges stay within their own space so scope='all' never bridges sheets, and include_geometry governs vertices/bulges. Only label_search is left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opening line states a specific resource and scope: the connectivity graph of the drawing as it currently is, with nodes, ports and edges. It is clear what the tool produces, but it never names or distinguishes itself from nearby tools such as pid_line_list, pid_equipment_list or drawing_topology_check, so sibling routing is left to the agent.

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?

There is one real usage cue: read stats.confidence_min before trusting a foreign drawing. There is no explicit statement of when to call pid_graph versus pid_line_list / pid_equipment_list / drawing_topology_check, and no preconditions such as which drawings are supported.

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