Automates AutoCAD plotting workflows, enabling inspection of DWG layouts, page setups, and publishing PDFs through a running AutoCAD instance.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CadPlot MCP Verify page setups and generate PDFs for all drawings in the approved folder"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
CadPlot MCP is a safety-first MCP server for repeatable AutoCAD plotting workflows. It is designed for architecture offices that need to inspect many revised drawings, identify sheet frames, map company page setups, and publish PDFs consistently.
The repository now provides:
recursive DWG discovery inside explicitly allowed folders;
read-only layout and plot-setting inspection through a running AutoCAD instance;
named page-setup inspection with expected PC3 and CTB/STB verification;
detection of paper-size labels such as 70x100, 700x1000 mm, or 50 × 70 cm;
configuration-based paper profile matching;
structured warnings suitable for an approval-first publish plan.
copy-only staging with a second SHA-256 check in the plug-in;
an opt-in, bounded queue drained on AutoCAD's main application context;
durable, authenticated queue intent: a Windows DPAPI-protected key outside the workspace signs
exact approvals; never-started work recovers after restart while an interrupted running job is
held as job_interrupted and is never replayed automatically;
durable pending cancellation: an exact signed tombstone survives restart, while a running PlotEngine operation is never force-aborted;
in-memory layout/page-setup/viewport creation and one PDF per sheet;
bounded, snapshot-consistent structural, physical-size, and nonblank PDF auditing, including a 64 MiB decoded-content cap and allocation-safe, 8 MiB marking lexer;
deterministic CycloneDX 1.7 SBOM generation bound to the exact commit, lock, runtime dependency inventory, wheel/source archive, and release DLL hashes, with no workstation paths or Autodesk binaries.
The executor compiles against an installed AutoCAD 2024 managed API surface. AutoCAD 2016 and
2025 release builds and live plotting still require the matching Autodesk SDK references and a
licensed-workstation acceptance test. Compile-only evidence is not presented as live evidence.
The repository and kit verifiers also do not claim Authenticode signing; an organization-owned
signing certificate and timestamp policy remain an external release gate. See the
software bill of materials.
The completion audit maps every project requirement to its current
authoritative evidence and keeps licensed/company-only gates explicit.
At load time the plug-in normalizes the real ACADVER value and refuses to enable publishing when
the loaded adapter does not match the running AutoCAD release.
Related MCP server: AutoCAD MCP Server - Codex Edition
No arbitrary AutoLISP or AutoCAD command execution.
No implicit use of ActiveDocument as the target.
Every DWG path must be inside an allowed root.
Every approved plan is bound to a two-pass stable source DWG SHA-256/size/time/file-identity fingerprint; redirected leaves and in-flight changes fail closed.
Drawings opened by the inspector are opened read-only and closed without saving.
Existing open drawings are never closed by the server.
Existing layouts are never selected as write targets; target-name collisions block the plan.
Staging copies a DWG into a new isolated job folder and refuses symlink/junction workspaces.
Python staging/audit and the plug-in re-hash the staged DWG before execution; Python evidence also requires two identical streaming fingerprint passes without loading large DWGs into memory.
Layouts and viewports are execution scaffolding: they are discarded after plotting, keeping the staged DWG byte-identical for the final audit.
Every sheet plots to an owned temporary PDF; final names appear only after every plot completes and the staged DWG closes without saving. A later promotion failure rolls back earlier unchanged outputs by length and SHA-256 when the filesystem permits it.
Existing PDFs, layouts, or busy plot engines cause refusal; overwrite remains disabled.
Publish commands are disabled unless the AutoCAD process starts with
CADPLOT_ENABLE_PUBLISH=1 and a trusted workspace.
Queue acceptance is acknowledged only after an immutable job-local intent is persisted. A separate started marker prevents ambiguous crash recovery from silently plotting twice.
Pending cancellation requires the exact plan and manifest digests, persists before memory state
changes, and is idempotent. Running or terminal work cannot be cancelled in place.
All MCP tools expose closed top-level structured-output schemas; plan and receipt identities also
carry exact digest patterns. Successful schema-v2 receipts bind the ordered PDF output set by
sheet index, filename, byte length, and SHA-256. The real STDIO smoke test exercises this contract
with call_tool.
MCP tool annotations distinguish local write actions from read-only tools; clients must still enforce their own approval policy because annotations are hints, not authorization.
Requirements: Windows, Python 3.11+, and AutoCAD for live DWG inspection.
cd cadplot-mcp
uv sync --extra autocad --extra dev
Copy-Item examples/config.example.yaml config.yaml
$env:CADPLOT_CONFIG = "$PWD\config.yaml"
uv run cadplot-mcpFor an administrator-authorized Secure MCP Tunnel developer pilot, run the same tool surface on a loopback-only Streamable HTTP endpoint:
uv run cadplot-mcp-http --port 8765This binds only 127.0.0.1 at /mcp, enforces exact Host/Origin guards, and caps requests at
1 MiB. It is not an authenticated public server and must not be forwarded with a generic tunnel or
reverse proxy. See loopback Streamable HTTP transport.
For the recommended private ChatGPT pilot target over STDIO, generate a secret-free administrator handoff report without contacting OpenAI or launching AutoCAD:
uv run cadplot-tunnel-preflight --transport stdio --probe-target `
--output C:\CadPlotPilot\chatgpt\tunnel-preflight.jsonSee Secure MCP Tunnel administrator handoff. Platform tunnel creation, runtime credentials, workspace permissions, and the live app scan remain administrator gates.
After those external gates pass, prepare the hash-bound 13-case ChatGPT tool-selection evaluation:
uv run cadplot-chatgpt-eval prepare `
--preflight C:\CadPlotPilot\chatgpt\tunnel-preflight.json `
--output-dir C:\CadPlotPilot\chatgpt\evaluation-001The sanitized validator tests direct, indirect, follow-up, approval, adversarial, edge, cancellation, and recovery behavior without retaining company paths or raw chat content. It proves the ChatGPT tool contract only and cannot replace licensed AutoCAD 2016/2025 evidence. See ChatGPT tool-selection evaluation.
Before connecting an MCP client, diagnose the local installation without launching AutoCAD:
uv run cadplot-doctor --mode config
uv run cadplot-doctor --mode inspection
uv run cadplot-doctor --mode fullconfig checks paths and policy only; inspection additionally requires a running AutoCAD COM
session; full also requires the installed local named-pipe plug-in and its trusted workspace.
Every mode is read-only and returns machine-readable JSON plus a nonzero exit code when not ready.
For a first office inventory, create a new empty local pilot folder without overwriting anything:
.\scripts\new-local-pilot.ps1 -DestinationRoot C:\CadPlotPilot -WhatIf
.\scripts\new-local-pilot.ps1 -DestinationRoot C:\CadPlotPilotThe script copies only the public non-matching inventory config and creates empty pilot-input and
pilot-work folders. It never copies company assets or enables publishing.
AutoCAD must already be running for inspect_drawing. The server will not launch it silently.
Each drawing inspection runs in a separate helper process with the bounded
inspection_timeout_seconds deadline (default 120). A hung COM call becomes an isolated file error
instead of freezing the MCP server or batch page. See
inspection isolation.
The local Python client and AutoCAD plug-in use the current-user pipe cadplot-mcp by default.
When licensed AutoCAD 2016 and 2025 instances must run at the same time, start each AutoCAD process
and its corresponding MCP server with the same distinct safe CADPLOT_PIPE_NAME, for example
cadplot-mcp-2016 and cadplot-mcp-2025. Also select read-only COM inspection with
CADPLOT_AUTOCAD_PROGID=AutoCAD.Application.20.1 for 2016 or
AutoCAD.Application.25.0 for 2025. CadPlot verifies the returned application version and refuses
ambiguous/foreign ProgIDs. Safe pipe names match [A-Za-z0-9._-]{1,128}; invalid names fail closed
on both sides. Never point one MCP process at an unverified AutoCAD instance.
Before AutoCAD testing, run the clearly labelled platform-independent synthetic demo:
uv run python scripts/run-synthetic-demo.pyvalidate_environment: report configuration and AutoCAD connection readiness.
get_autocad_plugin_status: verify the local read-only .NET plug-in bridge. When publishing is
enabled it also reports queueCapacity, queuePending, queueRunning, queueAvailable, and the
exact queueAuthentication scheme so large-run clients can apply backpressure without trusting
an unsigned restart queue.
scan_drawings: find DWG files under an allowed project folder.
inspect_drawing: read layouts, plot properties, labelled rectangular polylines, and strictly
validated orthogonal block frames backed by instance attributes or bounded read-only nested
definition text; the detector never explodes a block.
inventory_office_resources: produce a read-only exact-name inventory for frame labels, named
page setups, plotters, plot styles, canonical media, and candidate paper-space layouts without
approving any mapping.
create_publish_plan: generate a deterministic, hashed dry-run plan with blockers.
create_batch_publish_plans: inspect up to 50 drawings per restartable page while isolating
per-file blockers and AutoCAD errors; subsequent pages require the first page's exact
metadata-bound inventory ID.
preview_publish_plan: send only ready, hash-verified plan metadata to the local plug-in;
it never edits, saves, or plots the drawing.
stage_publish_job: require the exact approved plan ID, re-inspect and re-hash the DWG,
then create a verified working copy and audit manifest without plotting.
stage_publish_batch: stage at most 20 unique, explicit DWG/plan-ID approvals per call while
isolating per-file reinspection or approval failures.
validate_staged_job: ask the local plug-in to cross-check the staged manifest against its
independently configured trusted workspace; it first rejects a source DWG changed since staging
and does not queue or plot the job.
queue_publish_job: require the exact staged plan_id and manifest_sha256, then enqueue the
byte-bound copy-only job when the installed plug-in has explicitly enabled publishing. Source
SHA-256, byte length, and modification time are rechecked before the pipe call.
cancel_publish_job: durably cancel only the exact Pending plan/manifest identity. The signed
cancellation survives restart; the tool never interrupts a Running AutoCAD plot.
queue_publish_batch: queue at most 20 unique manifest/plan/hash approvals while isolating each
plug-in refusal or connection error. Schema v2 distinguishes retryable deferred items from
permanent failed items and stops issuing pipe requests after the first queue_full response.
get_publish_job_status: report Pending, Running, Succeeded, Failed, or Cancelled plus a bounded
machine-safe failure code.
get_publish_batch_status: read up to 20 exact plan IDs in one bounded MCP call, summarize live
states, and take one final internally consistent queue-capacity sample without writing files.
read_publish_receipt: recover immutable, manifest-and-output-digest-bound terminal execution
evidence from the staged job even after AutoCAD has restarted.
create_publish_operations_report: page through up to 50 staged workspace jobs with a stable
cursor, terminal evidence, output issues, safe next actions, and exact requeue approvals.
audit_publish_outputs: verify job boundaries, staged-DWG integrity, PDF structure, one-page
count, expected physical paper dimensions, nonblank marking content, sizes, SHA-256 hashes, and
execution evidence without changing output. publish_verified=true requires
source_unchanged=true, valid nonblank PDFs, and a successful receipt whose canonical output-set
binding independently revalidates.
match_paper_profile: map a detected label to a configured office profile.
Copy examples/config.example.yaml. Set workspace_root to a local,
dedicated output folder that is not a symlink or junction and does not overlap any allowed_roots
source tree. Unknown fields, malformed profile types, empty resource names, non-finite numeric
values, and unsafe tolerance ranges are rejected at startup. Company-owned DWT, CTB/STB,
PC3/PMP, title blocks, and project drawings must not be committed to this repository.
Run uv run python scripts/audit-source-tree.py before publication; CI and local preflight reject
tracked/non-ignored CAD assets, plot resources, archives, local config, and high-confidence secrets.
The same audit requires immutable full-SHA GitHub Action references, exact read-only workflow
permissions, non-persistent checkout credentials, and no pull_request_target; Dependabot is
configured for uv, NuGet, and Actions updates.
CI runs the complete Python suite on 3.11, 3.12, and 3.13, then runs the heavier canonical
release/MCP/.NET preflight once on 3.12. Full-SHA pinning alone is insufficient: the source audit
also rejects action repositories outside the explicit reviewed allowlist.
For a network-backed, lock-exact dependency check, run
scripts/run-local-preflight.ps1 -AuditDependencies. It audits the exported production Python lock
with hashes, all transitive .NET packages, and the Python license declarations. The resulting JSON
is bound to uv.lock; unknown licenses or known vulnerabilities fail the gate. Results are a
point-in-time database check, not a permanent security guarantee, and they do not launch AutoCAD.
If the exact office resource names are not yet known, follow the
read-only office profile onboarding with the deliberately
non-matching inventory config; do not guess production profile values.
A generic local stdio client example is available at
examples/mcp.local.example.json. Client configuration formats
vary; see deployment modes before connecting a managed ChatGPT
workspace. The ChatGPT connection architecture separates the
implemented local worker/loopback tunnel target from the still-unimplemented managed HTTPS bridge.
An optional validated Codex plugin wrapper is available under
integrations/codex/cadplot-mcp. It invokes an already
installed cadplot-mcp CLI and intentionally packages no DWGs, credentials, Autodesk binaries, or
office configuration.
drawing_unit_mm declares how many millimetres one model-space unit represents. Frame geometry
and the detected paper label are used to derive rotation and scale. Only values listed under
scale_denominators within scale_tolerance_ratio are accepted; nonstandard or distorted frames
remain blockers in the dry-run plan.
With require_page_setup_match: true (the default), a sheet is ready only when the named page
setup exists, its plot type is exactly Layout, its plotter and plot style match the configured
profile, and its paper-space plot scale is verifiably 1:1. Scale-to-fit is rejected because
viewport scale already carries the approved model-to-paper ratio. Planned layout names use
layout_prefix plus a deterministic index and frame handle; any existing-name collision blocks
the plan instead of overwriting a layout.
For custom PC3 paper definitions, set profile canonical_media to the exact value returned by
AutoCAD. The comparison is deliberately case-sensitive. Leave it unset only when the named page
setup is the accepted source of media configuration and the office has approved that policy.
pdf_page_tolerance_mm controls the final PDF MediaBox comparison and is capped at 10 mm.
minimum_frame_confidence defaults to 0.85; ambiguous/nested frame detection remains a blocker
below that threshold. See frame detection.
Set optional frame_layers when the office has a reliable frame-layer allowlist.
Set optional profile template_layout when each source DWG already contains an approved
paper-space title-block layout with exactly one floating viewport. The executor clones that layout,
preserves its paper-space geometry, and retargets the cloned viewport to the approved model window
and scale. Missing/model-space templates or zero/multiple floating viewports block execution.
An approved external DWG/DWT can be used only through the explicit three-part contract:
top-level template_roots, profile template_drawing, and the reviewed exact
template_sha256, together with template_layout. Planning inspects that asset read-only and binds
its layout/page setup/fingerprint into the plan ID. Staging re-hashes it and copies it under the
isolated job; the plug-in imports only that staged copy, re-hashes it again, and discards all imported
scaffolding with the staged DWG after plotting. No filename search or implicit office-library trust
is performed.
For large folders, retain the first create_batch_publish_plans result's inventory_id, then pass
it as expected_inventory_id with each returned next_offset until has_more=false. Pagination
fails closed if the DWG inventory changes. The hard page limit prevents a 300-file run from becoming
one fragile, opaque MCP request.
After staging and approving the returned manifest digests, use queue_publish_batch in bounded
pages; do not submit all 300 jobs as one call.
Read queueAvailable from get_autocad_plugin_status or the most recent queue/status response,
then retry the unchanged exact approvals reported as deferred when slots reopen. A queue_full
result is backpressure, not a publish failure and not permission to alter or silently replace an
approval. The MCP server instructions direct capable clients to keep feeding an already approved
large run autonomously; the operator still retains AutoCAD's publish opt-in gate.
Use get_publish_batch_status for bounded live polling instead of issuing one MCP call per plan;
its queue telemetry is sampled once after the per-job reads and is not claimed to be a simultaneous
snapshot of every job transition.
Restart state is reconstructed only from authenticated durable intent and immutable terminal
receipt.json evidence. Never-started pending work is restored; started work without a receipt is
held as job_interrupted and is not replayed. Use read_publish_receipt or the audit report to
resume verification without guessing from PDFs alone. Copying the workspace to another Windows
user or machine does not transfer pending authorization because the DPAPI key remains user-bound.
If a wrong profile or batch scope is discovered, call cancel_publish_job with the unchanged exact
plan and manifest digest for each still-pending item. Retry is idempotent. A job already reported as
Running is deliberately not aborted; wait for terminal evidence and review its outputs.
For a large run, call create_publish_operations_report until has_more=false, passing each
next_after_job_id to the next call. Its summary is page-local; retain every report_page_id as a
checkpoint. Only items in awaiting_execution include a queue_approval, and live status must be
checked before submitting it. A structurally valid cancellation marker is reported as
cancelled_hold without requeue approval; only the live plug-in authenticates it as Cancelled.
If the original DWG changed after staging, the item is source_changed, has no requeue approval,
and must be planned, approved, and staged again so a PDF from the older snapshot is never reported
as the current revision.
The local preflight also runs an explicit 300-drawing synthetic scale rehearsal:
uv run python scripts/run-synthetic-batch-demo.py --drawings 300It creates 300 non-DWG synthetic fixtures in a temporary directory, plans them in 15 immutable
pages, stages 300 independently hash-bound copies in 15 approval batches, saturates a synthetic
seven-slot queue and retries only the exact deferred approvals, walks the restart report without
repeats, reads all 300 plan identities through 15 bounded batch-status calls, and structurally
audits 300 generated PDFs. It deliberately creates no plug-in
receipt. Before the valid PDFs, it proves a portrait PDF cannot satisfy the landscape orientation
derived from the frame and records orientation_mismatch_rejected=true, including effective PDF
page rotation. It also proves a correctly sized blank page is rejected, then requires all 300 valid
PDFs to contain at least one decoded marking operator. All 300 valid
synthetic outputs still remain manual_review, execution_verified=0, and
publish_verified=0. This proves bounded local orchestration and fail-closed recovery at the target
count; it is not AutoCAD execution evidence.
Completed locally: discovery, inspection, deterministic planning, staging, queue protocol, executor source, synthetic workflow, and PDF audit.
Compile-verified locally: the shared executor against installed AutoCAD 2024 API assemblies.
Still required: matching-SDK bundle builds and live acceptance on licensed AutoCAD 2016 and 2025 with authorized office page setups/plot resources.
Implemented locally: loopback Streamable HTTP tunnel target with real protocol/header smoke.
Still external/optional: Secure MCP Tunnel admin provisioning or a managed authenticated remote gateway for a company ChatGPT workspace.
The repository contains separate adapters for AutoCAD 2016 (net45, release R20.1) and
AutoCAD 2025 (net8.0-windows, release R25.0). A normal solution build validates
the shared protocol without Autodesk binaries. A distributable bundle must be built with local
ObjectARX/AutoCAD managed reference folders:
.\scripts\build-bundle.ps1 `
-AutoCAD2016SdkDir "C:\ObjectARX2016\inc" `
-AutoCAD2025SdkDir "C:\ObjectARX2025\inc" `
-DotNet "$env:USERPROFILE\.dotnet\dotnet.exe"The script intentionally fails if the Autodesk reference assemblies are missing. Autodesk SDK
assemblies are development inputs and are not committed or copied into the public bundle. Before
compilation, all three managed assemblies must expose one consistent release series and the build
requires exactly R20.1 for the 2016 adapter and R25.0 for the 2025 adapter; a folder from another
installed AutoCAD release is rejected even when it contains the same DLL filenames.
An authorized operator can run the rehearsal, dependency audit, both exact-SDK builds, bundle verification, combined release-kit build, and final verification with one no-overwrite command:
.\scripts\build-complete-release.ps1 `
-AutoCAD2016SdkDir "C:\ObjectARX2016\inc" `
-AutoCAD2025SdkDir "C:\ObjectARX2025\inc" `
-DotNet "$env:USERPROFILE\.dotnet\dotnet.exe"See Autodesk SDK prerequisites. The SDK agreement remains an external operator gate; the project does not download, install, accept, or redistribute Autodesk development files.
A real build also requires a clean Git worktree and never replaces an earlier artifact. Its default
output is artifacts/cadplot-bundle-<version>-<commit>/, containing the extracted bundle, bundle
ZIP, and bundle-build.json. That manifest binds the exact commit, package version, redacted SDK
assembly identities/hashes, verified bundle file hashes, and archive hash while retaining
autocad_launched=false and live_publish_proven=false. verify-bundle-release.ps1 independently
checks the directory, manifest, ZIP entry set, and every inner file hash without extracting it.
After the clean matching-SDK bundle and a readiness report exist for the same commit,
scripts/build-release-kit.ps1 creates a no-overwrite transfer root containing that full bundle
release, the readiness-bound Python wheel, lock data, a git archive source snapshot, safe install
scripts, the inventory-only config, pilot evidence commands, and operator runbooks. The kit carries
its own hash-bound verify-release-kit.ps1, so verification and pilot collection need no separate
source checkout. The verifier checks both
manifests, the exact tree, embedded bundle/API evidence, current lock-bound Python/.NET vulnerability
evidence, the complete Python license inventory, and every outer ZIP entry without extracting it.
See verified release-kit installation. The kit keeps
licensed_live_pilot_ready=false, public_release_ready=false, and live_publish_proven=false;
only separately retained licensed 2016/2025 pilot evidence can change those claims.
Its install-release-kit.ps1 provides a single -WhatIf-capable, resumable first-install command:
it reuses only verified matching components, prepares pilot/Python first, and exposes the bundle last
without launching AutoCAD, changing global PATH, or enabling publish.
Bundle mutations refuse to run while acad.exe is active. A successful orchestrated install retains
a no-overwrite local receipt binding the release manifest, Python manifest, bundle hashes, and paths.
The included read-only verify-release-install.ps1 independently replays that complete evidence
chain later; expected inventory-config edits are reported without weakening immutable hash checks.
uninstall-release-kit.ps1 provides a receipt-bound, -WhatIf-capable and resumable rollback: it
removes the verified bundle before Python while deliberately preserving pilot data and the receipt.
The kit's install-python.ps1 first revalidates the whole transfer, installs exact frozen/hash-
required dependencies plus the wheel into a unique staging venv, and atomically names a version/
commit target without changing global PATH. verify-python-install.ps1 rechecks its retained wheel,
lock, requirements digest, command surface, and installed distribution inventory.
uninstall-python.ps1 revalidates that exact version/commit environment, previews with -WhatIf,
and removes only an atomically renamed quarantine; modified or redirected directories are preserved.
The smaller local demo builder creates a no-overwrite delivery directory containing the exact kit,
its ZIP, and an outer demo-kit-build.json. The embedded verify-demo-archive.ps1 checks the ZIP
without extraction, including safe entry names, exact membership, per-entry hashes, inner-manifest
identity, and false live-evidence flags. verify-demo-kit.ps1 independently verifies the flat kit,
which omits machine-local API directory paths from its portable manifest.
Before archiving or installing, scripts/verify-bundle.ps1 requires the exact six-file bundle,
checks both module routes and managed assembly identities, rejects extra files/reparse points, and
prints SHA-256 hashes. The build and install scripts invoke it automatically.
Licensed pilot assembly additionally binds JSON parsing and SHA-256 to one bounded stable
bundle-build.json snapshot, fingerprints the bundle ZIP before and after inspecting every entry,
and rejects redirected or in-flight changed evidence.
It also reads each 2016/2025 one-sheet and recovery JSON through an exact bounded two-pass snapshot
and rechecks all four after bundle and schema validation, before creating the no-overwrite combined
pilot record.
Installation copies into a uniquely named non-loadable staging directory, verifies every copied
file hash against the already verified source, and only then atomically renames it to
CadPlotMcp.bundle. The verifier rejects redirected files as well as redirected directories.
If copying or hash verification fails, the uniquely named non-loadable staging directory is
retained for explicit inspection instead of being recursively deleted by the installer.
scripts/run-local-preflight.ps1 exercises -WhatIf, installation, copied-hash verification,
-WhatIf removal, and removal with a clearly labelled protocol-only fixture; this smoke never
launches AutoCAD and is not a matching-SDK or live-publish result.
The installer never overwrites an existing bundle. It accepts only the exact CadPlotMcp.bundle
child of a full release root, then re-verifies the sibling ZIP, bundle-build.json, exact commit,
and matching-SDK evidence before copying anything. Protocol-only fixtures require an explicit
test-only switch and cannot pass as a real install. For an upgrade, close AutoCAD, preview the exact
removal with scripts/uninstall-bundle.ps1 -WhatIf, run it only after checking the target, then pass
the new build JSON's bundle path explicitly as install-bundle.ps1 -SourceBundle ....
The uninstaller rejects junctions and any directory whose
package name/ProductCode does not match CadPlot MCP. It also requires the exact verified bundle
contents and hashes twice, atomically renames the exact target to a unique non-.bundle quarantine,
and recursively removes only that checked quarantine. A rename/removal failure preserves evidence.
To compile-check the shared executor against a locally installed API without launching AutoCAD:
powershell -ExecutionPolicy Bypass -File .\scripts\probe-autocad-api.ps1 `
-AutoCADApiDir "C:\Program Files\Autodesk\AutoCAD 2024"The probe derives the managed target from the assembly identities (R20.1 → net45, R25.0 → net8.0-windows) instead of compiling every release through net48; unknown series are rejected.
This is only an API-signature probe. It does not validate plotting or version compatibility.
See publish executor and the
licensed-workstation pilot. A concise Turkish presentation flow is in the
Monday demo runbook.
The final two-version acceptance record is checked by the installed cadplot-validate-pilot
command (with scripts/validate-pilot-evidence.py retained as
a source-checkout wrapper); its completed company
evidence file stays outside the public repository. Live status exposes the embedded build commit
and running adapter DLL SHA-256. The pilot assembler derives the release commit from the verified
bundle-build.json, re-hashes every bundle ZIP entry, and refuses either version when its running
binary does not match the corresponding adapter artifact. Pilot schema v7 also requires the exact
authenticated durable-queue scheme and derives a
path-redacted external-template record from each immutable job manifest and requires the approved,
post-pilot company-source, and staged-copy hashes to remain identical. Each run also binds the
authorized one-page reference PDF and published output by path-redacted SHA-256/size/page geometry,
and independently revalidates the schema-v2 receipt's exact output count and output-set digest,
rejects a reference outside allowed roots or with different orientation/size during collection and
later validation, and requires seven separate visual-check attestations instead of one blanket switch.
It additionally requires a path-redacted 2–20 job post-restart recovery record from an isolated
workspace for each AutoCAD release; cadplot-collect-recovery independently replays every
manifest/receipt/PDF and source/staged hash before the final assembler can succeed.
After both one-sheet runs and both per-release recovery records pass, the installed
cadplot-acceptance finalizer binds that evidence to the exact
release-kit directory/ZIP, wheel, bundle, build manifest, commit, and package version. Its sanitized
report excludes company-run details and keeps public_release_ready=false until separate company
publication and maintainer release approvals are explicit; see
release acceptance.
The finalizer uses bounded stable JSON snapshots, pre/post release-ZIP fingerprints, retained
per-file fingerprints, and a final exact-tree comparison so a readiness result cannot mix release
manifest, pilot, archive-entry, or kit-file generations.
Before enabling writes on either licensed host, run the release kit's
scripts/test-licensed-workstation.ps1 with the exact install receipt and release (2016 or 2025).
It requires the version-specific COM ProgID/pipe, a running matching plug-in, unchanged install/config
evidence, and CADPLOT_ENABLE_PUBLISH unset. Its no-overwrite record proves only read-only workstation
readiness; it deliberately retains live_publish_proven=false and licensed_live_pilot_ready=false.
After every successful check it also emits a separate no-overwrite standard mcpServers JSON entry
bound to the verified installed interpreter, config, workspace, ProgID, and pipe. The read-only entry
omits the publish flag. Before recording success, the verifier launches that exact entry in a
sanitized environment and performs only MCP initialize and tools/list; it requires the exact
20-tool contract and records mcp_tools_called=false. This proves that the client entry is executable,
not that AutoCAD was launched, a DWG was opened, or a PDF was produced. The installed
cadplot-probe-client-config command can repeat this bounded check without invoking a CadPlot tool.
After the approved restart with CADPLOT_ENABLE_PUBLISH=1, run the same command with
-SessionMode Publish -ReadOnlyPreflightPath <the prior record> and a new output path. This second
gate uses cadplot-doctor --expect-publish-enabled to require the same install/runtime/binary identity
plus the DPAPI/HMAC authenticated queue. It does not queue a job or prove a PDF, so live and licensed
pilot readiness remain false until the one-sheet receipt, PDF audit, and visual review pass. Only a
config emitted by that successful publish-session gate contains exact CADPLOT_ENABLE_PUBLISH=1 and
may be merged into an approved local MCP client's configuration.
Before launching AutoCAD for staged-job validation, set CADPLOT_WORKSPACE_ROOT in the environment
that starts AutoCAD. It must resolve to the same directory as Python configuration
workspace_root. The plug-in never accepts a trusted workspace path from an MCP request.
Keep publishing off for inspection and staging validation. Enable it only for the authorized live
pilot by setting CADPLOT_ENABLE_PUBLISH=1 before starting AutoCAD; restart AutoCAD after changing
either environment variable.
MIT. Autodesk and AutoCAD are trademarks of Autodesk, Inc. This project is not affiliated with or endorsed by Autodesk.
Inspect expected PDFs and return hashes/statuses; never modifies the job or outputs.
| Name | Required | Description | Default |
|---|---|---|---|
| manifest_path | Yes | Explicit local path; it must pass CadPlot's configured path policy. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| job_id | No | |
| source | No | |
| outputs | No | |
| plan_id | No | |
| summary | No | |
| complete | Yes | |
| schema_version | No | |
| outputs_complete | No | |
| publish_verified | No | |
| source_unchanged | No | |
| execution_receipt | No | |
| execution_verified | No | |
| receipt_output_binding_verified | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the statement 'never modifies the job or outputs', which reinforces the safety profile and clarifies the scope of inspection, but does not disclose additional hidden behavior beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the primary action, followed by a safety guarantee. No redundant words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich set of annotations, a full output schema, and only one well-defined parameter, the description covers the essential behavioral context. It is complete for a simple read-only audit tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'manifest_path' with a clear description and 100% coverage. The tool description adds no information about the parameter, so the baseline of 3 applies as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect') and resource ('expected PDFs'), and states the return type ('hashes/statuses'). This clearly distinguishes it from siblings like get_publish_job_status or read_publish_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only audit use case through 'never modifies', but it does not explicitly state when to use this tool over alternatives such as inspect_drawing or scan_drawings. No direct references to sibling tools or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Durably cancel one exact pending job; never interrupts a running AutoCAD plot.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | Yes | Exact plan identifier returned by planning; write tools require explicit approval of this unchanged value. | |
| timeout_ms | No | Bounded local plug-in request timeout in milliseconds. | |
| manifest_sha256 | Yes | Exact lowercase SHA-256 digest returned by the preceding trusted step. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| plugin | No | |
| plan_id | No | |
| cancelled | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it states the cancellation is 'durable' and excludes running jobs, while annotations already flag the operation as destructive and idempotent. This gives the agent a clear safety model without contradicting the schema. The limitation is that it does not describe post-cancellation effects or error handling, so a score of 4 reflects good but not exhaustive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, well-structured sentence that front-loads the core action ('durably cancel one exact pending job') and then adds the key constraint ('never interrupts a running AutoCAD plot'). There is no filler or repetition of schema or annotations. This scores 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (100% parameter coverage), annotations that establish destructiveness and idempotency, and an output schema, the description covers the essential selection criteria and behavioral guarantees. It explains what the tool does, when it applies (pending), and what it avoids (running), which is sufficient for an agent to decide. It could mention prerequisites like obtaining plan_id and manifest_sha256 from prior steps, but the schema already indicates these are required and exact, so the description is contextually complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema, including patterns and validation constraints, so the baseline is 3. The description's mention of 'one exact pending job' reinforces the need for exact identifiers but adds no new parameter-level semantics beyond the schema. Thus the parameter semantics score remains 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as canceling a publish job, specifies it applies to pending jobs only, and distinguishes itself from any tool that could affect running plots. It includes a specific verb, resource, and scope, and the addition 'never interrupts a running AutoCAD plot' helps disambiguate from generic cancel operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: for a single pending job that must be canceled. It explicitly excludes running plots, giving a when-not condition. However, it does not mention alternative tools for batch cancellation or handling running jobs, so it falls short of full guidance; the sibling list includes other publishing tools but no other cancel tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a restartable page of DWGs; one drawing failure does not stop the batch.
| Name | Required | Description | Default |
|---|---|---|---|
| root | Yes | Explicit local path; it must pass CadPlot's configured path policy. | |
| limit | No | Bounded number of jobs or drawings returned in one page. | |
| offset | No | Zero-based drawing offset returned by the previous batch page. | |
| max_files | No | Safety cap for DWG discovery before pagination. | |
| recursive | No | ||
| expected_inventory_id | No |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| limit | Yes | |
| offset | Yes | |
| summary | Yes | |
| has_more | Yes | |
| processed | Yes | |
| next_offset | Yes | |
| inventory_id | Yes | Exact inventory identifier returned by the first batch page; subsequent pages must repeat it so file-list changes fail closed. |
| batch_page_id | Yes | |
| schema_version | Yes | |
| total_drawings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the annotations: it clarifies that the tool is restartable and resilient to individual drawing failures. This complements the readOnlyHint and idempotentHint without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. However, its brevity comes at the cost of clarity, omitting the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and a restartable pagination model, the description is incomplete. It fails to mention that the tool creates batch publish plans, how pagination works, or the role of expected_inventory_id in restartability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description gives no parameter-specific explanations. Schema covers 67% of parameters, but the description does not compensate for the uncovered parameter (recursive) nor connect pagination concepts to offset or expected_inventory_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Inspect' rather than 'Create', which conflicts with the tool's name 'create_batch_publish_plans'. It does not explicitly state that the tool creates batch publish plans; it describes a behavior (inspecting a restartable page of DWGs) rather than the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The phrase 'one drawing failure does not stop the batch' implies fault-tolerant batch processing, but it doesn't distinguish this tool from siblings like create_publish_plan or stage_publish_batch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize staged jobs as a restartable page and suggest safe next actions; never writes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Bounded number of jobs or drawings returned in one page. | |
| after_job_id | No |
| Name | Required | Description |
|---|---|---|
| error | No | |
| items | No | |
| limit | No | |
| summary | No | |
| has_more | Yes | |
| processed | Yes | |
| after_job_id | No | |
| report_page_id | No | |
| schema_version | No | |
| next_after_job_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by mentioning 'restartable page' (pagination behavior) and 'suggest safe next actions' (advisory output). The 'never writes' reinforces the read-only annotations without contradicting them. It does not detail error handling or prerequisites, but annotations already cover safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and includes the key safety note. Every phrase contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and rich annotations, the description adequately covers the tool's role, pagination, and non-write behavior. It doesn't explain return values (unnecessary with output schema) or edge cases, but the description combined with schema and annotations is sufficient for a straightforward read-only list-style tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for both parameters (limit, after_job_id), including the cursor pattern. The tool description adds the concept of 'restartable page', which aligns with after_job_id, but does not provide new parameter-specific information. With schema coverage at 50%, the description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Summarize staged jobs as a restartable page and suggest safe next actions.' It uses a specific verb ('summarize') and resource ('staged jobs'), and the phrase 'never writes' differentiates it from mutation tools. The name and title also align, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need an overview of staged jobs and safe next actions, and the 'never writes' note sets expectations. However, it does not explicitly mention when not to use it or reference alternative tools like audit_publish_outputs, so it lacks explicit exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect one DWG and return a deterministic dry-run plan; never modifies or plots it.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Explicit local path; it must pass CadPlot's configured path policy. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| ready | Yes | |
| sheets | Yes | |
| drawing | Yes | |
| plan_id | Yes | Exact plan identifier returned by planning; write tools require explicit approval of this unchanged value. |
| warnings | Yes | |
| schema_version | Yes | |
| drawing_fingerprint | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds 'deterministic' and 'never modifies or plots it', which goes beyond the annotations by specifying the exact behavioral guarantee. This is valuable additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and safety guarantee. There is zero redundancy or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 parameter), rich annotations, and presence of an output schema, the description adequately covers all necessary context: what it does, the single-file scope, determinism, and lack of side effects. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'path' parameter, with a description that explains the path policy. The tool description adds minimal extra meaning ('one DWG') that is already implied by the tool's purpose, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with specific verbs ('Inspect', 'return') and a specific resource ('one DWG'). It explicitly distinguishes this from batch operations by using 'one' and from actual publishing by stating it is a 'dry-run plan' and 'never modifies or plots'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use for a single DWG to get a deterministic dry-run plan without side effects. While no explicit alternatives are named, the sibling tool 'create_batch_publish_plans' is implicitly contrasted via 'one DWG', providing adequate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the installed AutoCAD plug-in through its read-only local named-pipe command.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout_ms | No | Bounded local plug-in request timeout in milliseconds. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| status | No | |
| connected | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the specific context of a 'read-only local named-pipe command,' which conveys a local IPC mechanism and implies that the plugin must be present for the check to succeed. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the core action and includes the key mechanism, making every word valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, output schema present, rich annotations), the description covers the essential context. It could note the dependency on the plugin being installed/running, but the phrase 'installed plug-in' plus the named-pipe mention partially implies this. Overall, it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter timeout_ms has full schema coverage with a clear description ('Bounded local plug-in request timeout in milliseconds'). The tool description adds little beyond this, but the schema alone is sufficient for understanding the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check the installed AutoCAD plug-in' via a specific mechanism ('read-only local named-pipe command'). It uses a specific verb+resource pairing and is distinct from sibling tools like get_publish_job_status, which are about publish operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking the plugin status but provides no explicit when-to-use guidance or alternatives. It doesn't mention when not to use this tool or how it compares to other tools, leaving usage context to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read up to 20 live job states and one final queue-capacity sample; never writes.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_ids | Yes | One to twenty unique exact plan IDs for a bounded live-status read. | |
| timeout_ms | No | Bounded local plug-in request timeout in milliseconds. |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| queue | Yes | |
| summary | Yes | |
| queue_error | Yes | |
| schema_version | Yes | |
| status_batch_id | Yes | Exact plan identifier returned by planning; write tools require explicit approval of this unchanged value. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: it clarifies the read is bounded ('up to 20'), that it includes exactly 'one final queue-capacity sample', and explicitly confirms 'never writes'. This goes beyond the annotations by specifying scope and non-mutation in operational terms, without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core action and key limits. It contains no filler or redundancy, and every word contributes meaning: 'Read', 'up to 20', 'live job states', 'one final queue-capacity sample', and 'never writes'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, the output schema exists, and the annotations cover safety, the description is nearly complete. It communicates the main scope and side-effect-free behavior. However, it lacks a hint about what the output structure looks like, although the output schema is present, so this is mostly covered. A minor gap is that it does not mention error handling or rate limits, but for such a bounded read tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to explain parameters. The schema already describes plan_ids as exact plan identifiers with constraints (max 20, min 1) and includes a note about write tools requiring approval. The timeout_ms parameter is also self-explanatory. The description adds no additional parameter semantics, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Read up to 20 live job states and one final queue-capacity sample.' This is a specific verb ('Read') with a specific resource ('live job states') and a distinguishing detail ('one final queue-capacity sample'). It also distinguishes itself from siblings like get_publish_job_status by indicating it covers up to 20 job states, indicating a batch-scope read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like get_publish_job_status or queue_publish_batch, nor does it state any conditional context (e.g., 'use this for batch status reads'). The only implicit hint is the 'batch' in the name, but the description itself offers no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a queued publish job state; never edits drawings or output files.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | Yes | Exact plan identifier returned by planning; write tools require explicit approval of this unchanged value. | |
| timeout_ms | No | Bounded local plug-in request timeout in milliseconds. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| found | Yes | |
| plugin | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description's 'never edits drawings or output files' reinforces this but adds only slightly more concreteness by naming the specific resources that are not modified. No new behavioral traits such as auth requirements or failure modes are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and a safety guarantee. It contains no fluff or redundant filler, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-status tool with two well-documented parameters, a rich output schema, and annotations covering safety and idempotency. The description sufficiently conveys what the tool does; the only minor gap is that it does not detail what statuses are returned, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both plan_id and timeout_ms, so the schema fully explains the parameters. The description adds no additional parameter semantics, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' with a clear resource 'queued publish job state', which distinguishes it from sibling tools like get_publish_batch_status and read_publish_receipt. It also adds a safety clause 'never edits drawings or output files' that clarifies the tool's side-effect-free nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for reading the state of a queued publish job, which implies when it should be used. However, it does not explicitly mention alternatives or exclusions, such as using get_publish_batch_status for batch-level status, so it lacks explicit differentiators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect one explicit allowed DWG/DWT read-only: layouts, plot settings, and frames.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Explicit local path; it must pass CadPlot's configured path policy. |
| Name | Required | Description |
|---|---|---|
| path | Yes | |
| frames | Yes | |
| layouts | Yes | |
| warnings | Yes | |
| page_setups | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by confirming the read-only nature and listing specific inspection targets (layouts, plot settings, frames), plus the 'allowed' constraint. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It immediately states the verb, resource, and scope, and every phrase ('explicit allowed', 'read-only', 'layouts, plot settings, and frames') carries meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with a rich output schema and comprehensive annotations, the description is complete. It covers the tool's purpose, scope (single allowed file), and content areas, while leaving return values to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the single 'path' parameter is fully explicit, including the CadPlot path policy. Since schema coverage is 100%, the description does not need to add further parameter details, and it doesn't, which is acceptable. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Inspect' and clearly defines the resource as 'one explicit allowed DWG/DWT' with concrete content ('layouts, plot settings, and frames'). It differentiates from sibling tools like scan_drawings by emphasizing the singular focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: for inspecting a single explicit DWG/DWT file. It provides clear context and the 'one' qualifier distinguishes it from batch operations. However, it does not explicitly name alternatives or provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inventory exact frame/layout/page-setup/plot resource names; never approves or writes.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Explicit local path; it must pass CadPlot's configured path policy. |
| Name | Required | Description |
|---|---|---|
| drawing | Yes | |
| warnings | Yes | |
| read_only | Yes | |
| next_action | Yes | |
| page_setups | Yes | |
| resource_names | Yes | |
| schema_version | Yes | |
| frame_observations | Yes | |
| template_layout_candidates | Yes | |
| requires_authorized_mapping | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds useful context beyond them: it explicitly states the tool never 'approves' (a separate non-write action) and emphasizes 'exact' names, indicating precision. This adds meaningful behavioral detail without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action verb. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter), rich annotations, and presence of an output schema, the description is fully sufficient. It covers purpose, non-write behavior, and precision, leaving no critical gaps for an agent to misuse it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the path parameter is fully described in the schema including the path policy requirement. The description itself adds no additional parameter semantics, consistent with the baseline of 3 when schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Inventory') and a specific resource ('exact frame/layout/page-setup/plot resource names'), clearly distinguishing it from sibling tools like create_publish_plan or preview_publish_plan. It also adds a clarifying negative scope ('never approves or writes'), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing resource names without side effects, but it does not explicitly state when to use this tool versus alternatives like scan_drawings or inspect_drawing. The phrase 'never approves or writes' provides an exclusion but lacks positive use-case context or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Match a frame's paper-size label to a configured office paper profile.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Paper-size label observed in or expected from a drawing frame. |
| Name | Required | Description |
|---|---|---|
| label | Yes | |
| matched | Yes | |
| profile | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds minimal context ('configured office paper profile') but doesn't disclose any additional behaviors like matching strictness or no-match handling. This is acceptable given the simple read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant or filler content. It front-loads the action and resource, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter read-only tool with complete annotations, full schema coverage, and an output schema present, the description is adequate. It lacks some context about matching behavior (e.g., exact match, case sensitivity) but is not critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the 'label' parameter with a clear description. The tool description doesn't add any extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'match' and the objects 'frame's paper-size label' and 'configured office paper profile'. It distinguishes this from sibling tools by focusing on the matching operation, though it doesn't explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus other tools. The description only states what it does, leaving the agent to infer appropriate usage from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a ready dry-run plan with AutoCAD; never edits, saves, or plots the DWG.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Explicit local path; it must pass CadPlot's configured path policy. | |
| timeout_ms | No | Bounded local plug-in request timeout in milliseconds. |
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| error | No | |
| plugin | No | |
| accepted | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses specific behavioral guarantees: 'never edits, saves, or plots the DWG'. This goes beyond the annotations (readOnlyHint, destructiveHint) by naming concrete actions it will not perform, which is highly valuable for the agent to understand side-effect boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence packed with purpose and behavioral constraints. Every word adds value; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety, schema covering parameters, and an output schema present, the description provides enough context for a validation tool. It explains what it does and what it avoids, though it could briefly mention what kind of validation result is returned, but the output schema likely handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage and both parameters (path, timeout_ms) are well-documented in the schema. The tool description itself adds no parameter-specific meaning, but schema already covers the semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Validate a ready dry-run plan with AutoCAD' – a specific verb, resource, and context. It also explicitly distinguishes itself by adding 'never edits, saves, or plots the DWG', which separates it from publishing/plotting tools and other validation tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a ready dry-run plan to validate, which is clear context. However, it does not explicitly mention alternatives or exclusions, even though sibling tools like validate_staged_job exist and operate in a related but distinct phase. Lacks explicit 'use this instead' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queue up to 20 approvals; capacity-full items are deferred for an exact retry.
| Name | Required | Description | Default |
|---|---|---|---|
| approvals | Yes | One to twenty unique manifest path, exact plan-ID, and exact manifest-hash approvals. | |
| timeout_ms | No | Bounded local plug-in request timeout in milliseconds. |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| summary | Yes | |
| complete | Yes | |
| queue_batch_id | Yes | |
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the write nature is known. The description adds valuable behavioral context: 'capacity-full items are deferred for an exact retry,' which is not covered by annotations. This explains a key non-obvious behavior, though it doesn't fully clarify retry semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that captures the core action and a key exception. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (100% parameter coverage) and presence of output schema, the description covers the primary action and the notable capacity behavior. Some ambiguity remains about the meaning of 'exact retry' and workflow placement, but overall it is sufficient for a queue operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for approvals and timeout_ms. The tool description adds no extra parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Queue up to 20 approvals' with a specific resource (publish approvals) implied by the title and sibling context. It distinguishes from sibling 'queue_publish_job' by the batch nature (up to 20). The verb 'Queue' is specific and the scope is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch queueing (up to 20 approvals) but does not explicitly state when to use this instead of alternatives like queue_publish_job. No exclusions or alternative guidance is provided, so usage is only implicitly conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queue an exact approved staged plan for PDF publishing; may create output PDFs.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout_ms | No | Bounded local plug-in request timeout in milliseconds. | |
| manifest_path | Yes | Explicit local path; it must pass CadPlot's configured path policy. | |
| approved_plan_id | Yes | Exact plan identifier returned by planning; write tools require explicit approval of this unchanged value. | |
| approved_manifest_sha256 | Yes | Exact lowercase SHA-256 digest returned by the preceding trusted step. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| plugin | No | |
| queued | Yes | |
| plan_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it discloses that the tool may create output PDFs, indicating a side effect beyond just queueing. It also emphasizes the need for an 'exact approved' plan, implying validation behavior. This is valuable since the annotations only specify readOnlyHint false without detailing the nature of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the tool's purpose in a front-loaded manner. It avoids unnecessary verbosity and each phrase adds meaning—'exact' signals approval constraints, 'may create output PDFs' notes potential side effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and annotations, the description provides sufficient context without needing to detail return values. It covers the key prerequisite (staged plan) and the action (queue), while the schema and annotations handle the rest. It could be slightly more explicit about prerequisites, but it is overall adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides comprehensive descriptions for all 4 parameters covering 100% of their semantics. The description does not add meaningful parameter-level detail beyond the schema's existing information, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Queue an exact approved staged plan for PDF publishing.' It uses a specific verb ('queue'), identifies the resource ('approved staged plan'), and specifies the purpose ('PDF publishing'). This distinguishes it from sibling tools like stage_publish_job (staging) and queue_publish_batch (batch queueing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like queue_publish_batch or when not to use it. The 'exact approved staged plan' language implies prerequisites, but no direct usage instructions or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read persistent terminal publish evidence after AutoCAD restarts; never writes files.
| Name | Required | Description | Default |
|---|---|---|---|
| manifest_path | Yes | Explicit local path; it must pass CadPlot's configured path policy. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| found | Yes | |
| receipt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds context about persistence and the restart scenario, but 'never writes files' is redundant with the annotations. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action and resource, and includes a clear side-effect guarantee. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter), rich annotations, and presence of an output schema, the description is nearly complete. It provides the key scenario ('after AutoCAD restarts') and read-only guarantee, though it could have mentioned what the returned evidence contains or any prerequisites, but the schema covers parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter (manifest_path), with its own description about local path policy. The tool description adds no new parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Read') and the resource ('persistent terminal publish evidence'), with the specific condition 'after AutoCAD restarts'. This distinguishes it from sibling tools that create, stage, or queue publish jobs, and the explicit 'never writes files' reinforces its read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: after AutoCAD restarts, when persistent evidence is needed. It does not explicitly name alternative tools or state when not to use it, but the 'never writes files' hints at a safe read-only alternative to write operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List DWG files under an explicitly allowed project root without opening them.
| Name | Required | Description | Default |
|---|---|---|---|
| root | Yes | Explicit local path; it must pass CadPlot's configured path policy. | |
| max_files | No | Safety cap for DWG discovery before pagination. | |
| recursive | No |
| Name | Required | Description |
|---|---|---|
| root | Yes | |
| count | Yes | |
| drawings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds meaningful context beyond those: files are not opened, and the path must pass CadPlot's configured path policy, which is an authorization-related behavioral detail. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, front-loaded with the verb and object. Every phrase contributes meaning, with no filler, tautology, or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations (readOnly, idempotent, non-destructive) and the presence of an output schema, the description sufficiently conveys purpose and key constraints. It could mention max_files or recursive behavior, but the schema covers most parameters, so the description is complete enough for tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents root and max_files with descriptions, giving 67% coverage, but recursive has no description. The overall description reinforces the root policy but does not add semantics for max_files or recursive, leaving recursive's meaning implicit in its schema default of true.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'List' with the resource 'DWG files' and adds valuable scope: 'under an explicitly allowed project root' and 'without opening them'. This clearly distinguishes it from the sibling inspect_drawing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a clear prerequisite: the root must be an explicitly allowed project root, which gives context for when this tool is applicable. It does not explicitly name alternatives or exclusions, though 'without opening them' hints that it is not for inspecting file contents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stage up to 20 explicit DWG/plan-ID approvals; never plots or edits originals.
| Name | Required | Description | Default |
|---|---|---|---|
| approvals | Yes | One to twenty unique explicit DWG path and exact plan-ID approvals. |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| summary | Yes | |
| complete | Yes | |
| schema_version | Yes | |
| approval_batch_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety hints (all false), so the description carries the burden. It adds a key constraint ('never plots or edits originals'), but does not disclose other potential side effects of staging (e.g., whether it writes files, is stateful, or requires downstream validation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the verb and includes the most important constraints (limit and non-destructive guarantee).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich schema and an output schema, the description is appropriately sized. It covers the batch limit and safety, but could benefit from a brief mention of the staging workflow (e.g., must be followed by validate_staged_job or queue_publish_batch). Overall sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage, including path and plan_id constraints. The description adds only the batch limit (up to 20), which duplicates schema maxItems, and no additional parameter-specific meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the action ('Stage') and the resource ('up to 20 explicit DWG/plan-ID approvals'). Distinguishes from siblings like stage_publish_job (singular) and queue_publish_batch (queueing) by focusing on batch approval staging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for staging multiple approved plans before validation/queueing, but does not explicitly state when to use it over stage_publish_job or queue_publish_batch. It mentions 'explicit' approvals, which signals a prerequisite, but offers no alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revalidate an approved plan and copy its DWG into an isolated workspace; never plots.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Explicit local path; it must pass CadPlot's configured path policy. | |
| approved_plan_id | Yes | Exact plan identifier returned by planning; write tools require explicit approval of this unchanged value. |
| Name | Required | Description |
|---|---|---|
| job | No | |
| plan | Yes | |
| error | No | |
| staged | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only false hints, so the description carries the burden. It adds meaningful context: the operation revalidates, copies into an isolated workspace, and explicitly guarantees never plots. This goes beyond the annotation fields and gives a clearer behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary action, states the resource, and includes a critical constraint ('never plots'). Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool is one step in a pipeline, the description covers the core behavior. It mentions isolation and the no-plot guarantee, which are important context. It lacks explicit prerequisites (e.g., plan must be approved) but those are partially implied by the name and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover both parameters 100% (path and approved_plan_id). The description adds a slight hint that 'approved plan' maps to approved_plan_id and the DWG relates to path, but it doesn't clarify whether path is the source or destination. Overall it adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('revalidate', 'copy') and names the key resources ('approved plan', 'DWG', 'isolated workspace'). The phrase 'never plots' clearly differentiates it from plotting/publishing siblings like queue_publish_job and preview_publish_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after plan approval and before plotting, but it does not explicitly state when to use this over alternatives like stage_publish_batch or validate_staged_job. The only exclusion is 'never plots', but there is no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate configuration, allowed roots, and the read-only AutoCAD COM connection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| ready | Yes | |
| config | Yes | |
| errors | Yes | |
| plugin | Yes | |
| autocad | Yes | |
| workspace | Yes | |
| allowed_roots | Yes | |
| paper_profiles | No | |
| schema_version | Yes | |
| template_roots | Yes | |
| workspace_root | Yes | |
| template_assets | Yes | |
| allowed_root_status | Yes | |
| template_root_status | Yes | |
| inspection_timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the exact items being validated (configuration, allowed roots, connection), and it reinforces the read-only nature of the COM connection. It does not contradict annotations and contributes useful context beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise and front-loaded. It communicates the core purpose without any superfluous words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple validation tool with no parameters and an output schema (indicated by context signals), the description is largely sufficient. However, it could be slightly more complete by noting its role in the pre-publish workflow or differentiating when to use it over get_autocad_plugin_status. Still, the essentials are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the input schema is empty. This score reflects that the no-parameter scenario is well handled without any additional burden on the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('validate') and identifies three concrete targets: configuration, allowed roots, and the read-only AutoCAD COM connection. This distinguishes it from sibling tools like inspect_drawing or get_autocad_plugin_status by focusing on environment-level validation rather than drawing inspection or plugin status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description explains what it validates but not when it should be invoked (e.g., before publishing, as a pre-flight check, or how it relates to get_autocad_plugin_status). This leaves the agent without explicit decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-check a staged manifest with the local plug-in; never queues or plots the job.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout_ms | No | Bounded local plug-in request timeout in milliseconds. | |
| manifest_path | Yes | Explicit local path; it must pass CadPlot's configured path policy. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| plugin | No | |
| accepted | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint, idempotentHint, and destructiveHint already provided, the description adds extra behavioral context by noting it 'never queues or plots the job' and works with the 'local plug-in'. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary action and includes a key exclusion. Every word earns its place with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, rich annotations, and presence of an output schema, the description is complete. It states the action, the non-actions, and the local scope, making it fully adequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents both parameters. The description does not add any parameter-specific meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cross-check a staged manifest') and the resource ('with the local plug-in'). It distinguishes from siblings by explicitly noting 'never queues or plots the job', which separates it from queue_publish_job and plotting tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (validating a staged manifest) and includes an exclusion ('never queues or plots'). However, it does not explicitly name alternative tools or state 'use this instead of X', leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0audit_publish_outputscancel_publish_jobcreate_batch_publish_planscreate_publish_operations_reportcreate_publish_planget_autocad_plugin_statusget_publish_batch_statusget_publish_job_statusinspect_drawinginventory_office_resourcesmatch_paper_profilepreview_publish_planqueue_publish_batchqueue_publish_jobread_publish_receiptscan_drawingsstage_publish_batchstage_publish_jobvalidate_environmentvalidate_staged_jobMost tools have clear, distinct purposes (inspect, plan, stage, queue, status, cancel, report), and batch variants are explicitly differentiated by plural names and descriptions. A few similar verbs like 'validate_environment' and 'validate_staged_job' or 'inspect_drawing' and 'inventory_office_resources' could cause minor selection uncertainty, but descriptions resolve the boundaries.
The naming follows a consistent verb_noun pattern throughout (inspect_drawing, scan_drawings, create_publish_plan, stage_publish_job, queue_publish_batch, cancel_publish_job, read_publish_receipt). All verbs are lowercase with underscores, and the pattern is predictable across the full set.
At 20 tools, the server sits in the 'heavy but justifiable' range. The detailed publishing pipeline requires many steps, but the count is above the typical well-scoped 3-15 and feels close to the boundary where consolidation (e.g., merging plan and preview) might improve usability.
The tool set covers the full lifecycle from inspection and planning through staging, queuing, status monitoring, cancellation, and receipt reading, plus environment validation and resource inventory. Minor gaps exist, such as no batch cancellation or direct job modification, but these are not critical for the core publishing workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for detecting and redacting PII (Personally Identifiable Information) in PDF documents.
AutoRender's MCP server for media assets, transformations, delivery, and workflow automation.
The MCP server that vets MCP servers: identity, risk grade and per-tool risk before you install.
Conformance checker for MCP servers. Free, no key, verdicts recomputable and re-measured daily.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/agadraphy/cadplot-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
