Skip to main content
Glama
Sign In
AutoCAD MCP Pro

AutoCAD MCP Pro

by U-C4N
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

P&ID: From Spec

pid_from_spec

Draws a P&ID from a spec in one all-or-nothing transaction: places equipment, valves, instruments and connectors, routes lines port-to-port, and rolls back on invalid items or stale revision.

Instructions

Equipment, valves, instruments and connectors placed, then every line drawn port-to-port, inside one transaction: any bad item rolls the whole sheet back and the error names it (lines[2].to); so does an interruption (a client cancellation mid-run leaves no half-drawn sheet and no open transaction on either engine — the live one goes back to the UNDO Mark transaction_begin set, so it never waits at an AutoCAD prompt; should that rollback itself fail, the failure is logged, the cancellation is what the client sees, and the drawing must be checked before a retry). A non-finite coordinate, rotation, scale or stub is refused by path before anything is placed. The response carries the graph read back from the drawing and the P&ID critique issues, so the caller sees dangling ends or duplicate tags in the same round trip. dry_run returns the planned vertices and crossings without touching the drawing; crossings are counted, on both runs, against the spec's own lines and the P&ID lines already on the current layout (crossings_scope). The dry run also returns the routing region and a preview whose precondition is the fingerprint of every entity in that region. Applied with the preview's revision (expected_revision) and/or preconditions, the run is refused with kind stale_revision and nothing drawn when anything in the region (or the revision) changed; a region precondition taken from another spec is refused by path. A guarded run reports revision ({checked, after, interleaved}).

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": {
      "spec": "<spec>"
    },
    "name": "pid_from_spec"
  }
}

Input Schema

NameRequiredDescriptionDefault
specYes{sheet, equipment[], valves[], instruments[], lines[], connectors[]} — see the P&ID prompt
dry_runNoValidate and route in memory; draw nothing
preconditionsNoA dry run's `preview.preconditions` (the routing region's fingerprint): draw only if nothing in the region changed; otherwise refused stale_revision and nothing is drawn.
expected_revisionNoDraw only at this content revision (a dry run's `preview.revision`); otherwise refused stale_revision and nothing is drawn.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.7.0
    • addedInput schema / properties / expected_revision
      Added value: +{
+  "anyOf": [
+    {
+      "minimum": 0,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Draw only at this content revision (a dry run's `preview.revision`); otherwise refused stale_revision and nothing is drawn."
+}
    • addedInput schema / properties / preconditions
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "A dry run's `preview.preconditions` (the routing region's fingerprint): draw only if nothing in the region changed; otherwise refused stale_revision and nothing is drawn."
+}
  2. Addedv1.6.0

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the lone readOnlyHint=false annotation, the description discloses atomic all-or-nothing rollback, error item naming (lines[2].to), cancellation behavior (UNDO Mark restore, no open transaction), non-finite input refusal by path, and what the response carries. This is exactly the extra behavioral context annotations cannot supply.

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 core action is front-loaded in the first sentence, but the body is a dense, deeply nested parenthetical that is hard to parse in one read. Much of the cancellation/rollback-failure detail is valuable but verbose enough to obscure the primary instructions.

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 complex transactional tool with a nested spec object and an output schema present, the description covers atomicity, preview/guard semantics, and response contents adequately. The spec's internal structure is left to external documentation, a minor gap.

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; the description adds real meaning about the dry_run/preview/revision loop — crossings_scope, the region fingerprint precondition, and stale_revision refusal semantics — that goes beyond the per-parameter schema text. It stops short of describing the spec object's internal shape, which it defers to the prompt.

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?

The opening sentence states a specific verb and resource set — equipment, valves, instruments and connectors placed, then every line drawn port-to-port, inside one transaction — so the agent can tell this builds a whole P&ID sheet from a spec rather than inserting individual symbols. It does not explicitly contrast itself against siblings like pid_graph or pid_symbol_insert, so it falls just short of a 5.

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 clearly lays out the dry_run-first workflow and when to apply preconditions/expected_revision (guarded run, refusal on stale_revision). It does not explicitly say when NOT to use this versus the atomic entity/pid_* primitives, but the operating context is clear enough to route correctly.

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