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

Batch: Run Tools

cad_batch
Destructive

Execute an ordered list of CAD tool calls in one request, validating each step and referencing earlier results. Dry-run and revision checks preview and safely apply batches.

Instructions

Execute an ordered list of tool calls in ONE round trip.

N calls collapse into one request/response pair, and bind lets a later step reference an earlier step's result so handles never have to be echoed back through the model.

steps=[
  {"tool": "entity_create_line",  "args": {...}, "bind": "edge"},
  {"tool": "point_from_snap",     "args": {"handle": "$edge", "snap": "mid"},
                                  "bind": "mid"},
  {"tool": "entity_create_circle","args": {"cx": "$mid.x", "cy": "$mid.y",
                                           "radius": 4}},
]

Successful steps report only their handle; pass verbose=True for the full result. Anything without a handle is returned whole.

VALIDATION runs first, always: an unknown tool, a schema-invalid argument or a reference no earlier step binds refuses the whole batch before anything executes. on_error governs run-time failures only. dry_run=True returns that validation report and executes nothing.

ERRORS are typed, never text: each failed step carries error.kind - one of unsupported (with the backend capability), invalid_args, refused, failed, unknown_tool, unresolved_ref, denied, malformed_step, quarantined, busy, active_document_changed (live engine: the operator switched documents), stale_revision, scan_incomplete, timed_out, unknown_commit (a write that outran its deadline while its worker ran), cancelled, operation_conflict - and its own operation_id.

PREVIEW AND APPLY. dry_run=True also returns preview: the document id and content revision, the exact fingerprint of every LITERAL handle in a handle parameter (a '$reference' resolves late and an entity a step creates has none) and the planned steps. Pass its revision as expected_revision and its preconditions back, and the batch runs only if nothing moved - otherwise it is refused with kind stale_revision and no step runs. A guarded batch reports revision: {checked, after, interleaved}; each step is its own locked call, so a change another call made between two steps is listed under interleaved (a rollback restores the checkpoint, that change included).

OPERATIONS: the batch and each step are operations with their own ids (system_status lists the recent ones). Pass operation_id (or the request's _meta.operation_id) to make a retry safe: the same id with the same steps replays the recorded result instead of drawing twice. The journal is in memory: a server restart forgets it (durable in 1.8.0, B13).

ATOMICITY is reported, not assumed. Read the atomicity block: on the headless backend rollback restores a full document snapshot; on live AutoCAD it sends an UNDO whose landing AutoCAD never confirms. The default on_error="stop" claims nothing and is exact on both. A checkpoint a step opens with transaction_begin is closed with the batch's (unwound).

NOT CALLABLE from a batch: the raw command/LISP escape hatches, and cad_batch itself. Call those directly.

For a few hundred entities of the same kind, entity_batch_create is denser still (no per-step tool name) - and it can be one step of a cad_batch.

Input Schema

NameRequiredDescriptionDefault
stepsYesOrdered steps. Each: {'tool': <tool name>, 'args': {...}, 'bind': <optional name>}. 'bind' names this step's result so a later step can reference it as '$name' (its handle), '$name.field' or '$name.list.0'. '$$' is a literal dollar sign.
dry_runNoValidate every step against its tool's real JSON Schema and execute nothing.
verboseNoReturn each step's full result instead of just its handle.
on_errorNostop (default): halt at the first failure, keep what already ran. continue: run every step. rollback: open a checkpoint first and undo on failure - read the returned `atomicity` block for what that is worth on this backend.stop
operation_idNoYour own id for this batch (1-128 printable characters). Sent again with the same steps it returns the recorded result (replayed: true) instead of running twice; with other steps it is refused (operation_conflict); after a run whose outcome is unknown (cancelled or timed out mid-write) it is refused (requires_reconcile). Held in memory only: a server restart forgets it.
preconditionsNoA dry run's `preview.preconditions` ({handle, fingerprint} per literal handle): run only if every entity is exactly as previewed; otherwise refused stale_revision, no step run.
expected_revisionNoRun only if the document's content revision is still this one (a dry run's `preview.revision`); otherwise refused stale_revision, no step run.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.7.0
    • addedInput schema / properties / expected_revision
      Added value: +{
      +  "anyOf": [
      +    {
      +      "minimum": 0,
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Run only if the document's content revision is still this one (a dry run's `preview.revision`); otherwise refused stale_revision, no step run."
      +}
    • addedInput schema / properties / operation_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Your own id for this batch (1-128 printable characters). Sent again with the same steps it returns the recorded result (replayed: true) instead of running twice; with other steps it is refused (operation_conflict); after a run whose outcome is unknown (cancelled or timed out mid-write) it is refused (requires_reconcile). Held in memory only: a server restart forgets it."
      +}
    • 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` ({handle, fingerprint} per literal handle): run only if every entity is exactly as previewed; otherwise refused stale_revision, no step run."
      +}
  2. Addedv1.5.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say destructive/not read-only; the description adds a great deal beyond that: validation-first refusal semantics, typed error kinds, dry_run preview/apply with fingerprint+revision guards, the non-durable in-memory journal, idempotent replay via operation_id, and the honest caveat that rollback on live AutoCAD sends an unconfirmed UNDO.

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?

Front-loaded with purpose and a worked example, then organized into labeled sections (VALIDATION, PREVIEW AND APPLY, OPERATIONS, ATOMICITY). Dense and useful, but long and occasionally verbose (e.g., the 'durable in 1.8.0, B13' aside) for what could be tighter.

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 complex meta-tool with 7 params, annotations, and an output schema, nothing critical is missing: error taxonomy, atomicity trust level, idempotency, revision race handling, and exclusions are all covered.

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 the baseline is 3. The description adds real meaning over the schema: it explains the `$reference` late-resolution rule, how a dry run's `preview.revision` and `preconditions` feed back into `expected_revision`/`preconditions`, and the replay-vs-conflict behavior of operation_id.

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 the verb and resource precisely: 'Execute an ordered list of tool calls in ONE round trip.' The example plus the note that it can't call the raw escape hatches or itself makes the scope unmistakable against siblings.

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

Usage Guidelines5/5

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

Explicitly covers when to use it (collapse N calls into one round trip, use `bind` to thread handles), the denser alternative for bulk same-kind entities (entity_batch_create), and what it cannot be used for (raw command/LISP hatches, cad_batch itself) which must be called directly.

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