warehouse-cad-agent ist ein Windows-first Codex Plugin und eine Python-Engine für nachvollziehbare Warehouse-CAD-Roundtrips:
jede Modellraum-Entität in einer deklarierten DXF oder in einer DWG prüfen, deren DXF-Lesekonvertierung einen passenden Hash-Beleg besitzt;
sichtbares Equipment von der Struktur trennen, ohne unaufgelöste Kandidaten stillschweigend zu akzeptieren;
ein einziges, in sich geschlossenes Markdown-Equipment-Ledger schreiben;
bearbeitbare 2D-CAD ausschließlich aus der leeren CAD-Datei und jedem Ledger neu aufbauen;
belegbegrenztes portables 3D und natives AutoCAD-3DSOLID erzeugen, wenn vollständige, quellengestützte Nachweise für Fußabdruck, Höhe und Elevation vorhanden sind;
einem Agenten erlauben, eine automatisch erstellte AutoCAD-Arbeitskopie über fünf begrenzte MCP-Tools zu inspizieren und zu bearbeiten.
Das Projekt leitet bewusst nicht fehlende Geräteidentität, Höhe, Elevation, Durchflussrichtung, Anschlüsse oder Herstellergemetrie ab. Ein Protokoll-Handshake, ein Screenshot, eine Datei-Existenzprüfung oder ein Zähler ausgewählter Ausgaben gilt nicht als Beleg dafür, dass ein angeforderter CAD-Artefakt vollständig ist.
Dieses Repository enthält nur die generische Engine, das Plugin, die Skill, die MCP-Bridge, synthetische Fixtures und den Verifikationscode. Kundenzeichnungen, Kundennamen, Quell-Hashes, private Klassifikationsprofile und Ausliefernachweise gehören in ein separates, privates Integrations-Repository.
Related MCP server: AgentCAD
Voraussetzungen: Python 3.11+ und optional eine auf CAD-Laufzeit gebrauchte, vollständige AutoCAD für Live-Bearbeitung und native DWG-Solids. Autodesk DWG TrueView ist keine beschreibbare AutoCAD-Laufzeitumgebung.
Verwaltete AutoCAD-Öffnungen verwenden DWGCHECK=0 nur vorher um Documents.Open herum, warten nach dem Öffnen, bis AutoCAD wieder in Ruhe ist, und stellen danach den vorherigen exakten Wert wieder her und prüfen ihn. Dies unterdrückt nur die Warnung für Nicht-Autodesk-Hersteller, während der Korruptionsfehler-Dialog von AutoCAD erhalten bleibt; die Zeichnung wird nicht für gültig erklärt.
Die Erstellung von Live-Prüfvermerken ruft den nicht idempotenten AddText-Aufruf nie erneut auf. Wenn AutoCAD nach der Erstellung von etwas einen Fehler meldet, verwendet die Bridge zusätzlich zum kompletten Snapshot der Modellraum-Handles vor dem Schreiben die Angaben von Typ, und Höhe, um genau eine eindeutig zusch Neues Text-Entität wiederherzufinden. Der Vermerk, seine Ebene und der registrierte Anwendung gehören zu einer Undo-Transaktion. Jedes bekannte Feld/attribut wird höchstens einmal geschrieben und zurückgelesen. Wenn ein unvollständiges Ergebnis den Snapshot aus Handles/Ebene/registered application verändert hat, fordert die Bridge genau ein Undos aus und verifiziert alle drei Schichten; wenn der Snapshot nie verändert wurde, führt kein Undo durch und versprochen kein Rollback. Jede nichtbelegte Wiederherstellung erhält die verwaltete Arbeitskopie und eine strukturierte Partial-Edit Fehler.
Die Abnahme zum Speichern, Schließen und Wiederöffnen kann einen frischen, vom Agenten gestarteten AutoCAD-Prozess verwenden. Die Session-Aktion shutdown ist fail-closed: Sie fordert keine verwaltete Session, eine Control-Zeichnung, null offene Dokumente und den bestätigten Exit der mit dem Anwendungsfenster verknüpfen Prozess. Ihr optionaler Fallback force_if_graceful_timeout=true ist auf einen einzelnen Agenten-Prozess beschränkt: Nachdem ein regelmäßiges Application.Quit ohne Timeout nicht abgeschlossen ist, muss die Bridge erneut bestätigen, dass AutoCAD bei null Dokumenten im Leerlauf üben ist, befestigte itterminates an dem bereits gebundenen Windows-Handle-Prozess einmal durchführt. Sie schlotzt nie eine AutoCAD-Anwendung, die der Agent nur dell arkattached; solche nicht angehängt.
py -3.11 -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e ".[dev]"
.\.venv\Scripts\warehouse-cad-agent doctor
.\.venv\Scripts\python.exe examples\synthetic\make_fixture.py
.\.venv\Scripts\warehouse-cad-agent roundtrip examples\synthetic\project.yamlDas Codex-Repository-Marketplace-Manifest ist .agents/plugins/marketplace.json. Den geklonten Repository als lokalen Marketplace registrieren, das Plugin installieren und einen neuen Codex-Thread starten:
git clone https://github.com/X-isdoingreat/warehouse-cad-agent.git
Set-Location warehouse-cad-agent
codex plugin marketplace add .
codex plugin add warehouse-cad-agent@warehouse-cad-agentRufen Sie in diesem neuen Thread $warehouse-cad-agent auf. Die Marketplace-Authentifizierung ist ON_USE: approval Sie die SQLite lokale MCP-Nutzung interaktiv. Eine nicht-interaktive Konfiguration mit approval=never erkennt die fünf Tools, dennoch muss die App aufrufen abgerufen es sei denn, der Aufruf ist explizit erlaubt.
project.yaml ist die Ausfall-Allowlist. Ein eindeutiges source.read_dxf muss source.read_conversion_receipt enthalten; unaufgelöste Objekte dürfen nur durch den source.resolution.inventory zusätzlich plus source.lösung.ledger klassifiziert werden. Das Datenstattment betrachtet die Datei, aber alleine bleibt es ohne das. Auswahlbasis.
Blind CAD und Markdown werden nicht als ersetzbar für gültige Dateien angesehen:
die leere CAD trägt eine eingebettete Projekt- und Quellbindung;
das Markdown-Ledger bindet die SHA-256 der leeren Datei exakt;
ein Neuaufbau verweigert jede übereinstimmende oder veränderte Kombination, bevor er Ausgabe schreibt.
Kundenadapter, die native-Solid-Spezifikationen erzeugen, verwenden dieselbe "leere-Blatt-Regel, keep eine definierte Annahme für das vorherige Quell-Ledger, getrennt vom vorherigen, für das aktuelle native CAD-Produktziel.
Der Weg aus synthetischer Blank + Markdown + isolierter 2D + portabler 3D und ein frischer Codex/MCP doctor-Aufruf wurde lokal getestet. Auf genau einer synthetischen DWG hat das installierte Plugin zusätzlich feststellen, wie es Test- AutoCAD 2027 Trial create / query / rollback / save and fresh-process reopen. Außerdem ist eine genaue, private, hash-gebundene Warehouse-DWoG-Quelle mit einem Equipment-Ledger-Set Grund, native 3DSOLID-Erzeugung, finale DWG speichern, version-matched ObjectDBX-Reopen, record-level agent identity/geometrie reconciliation und Schluss-Abgleich im echten AutoCAD 2027-Test* to to. These are less narrow source-set results, no general Manufacturer-Modell, complexity-engine, or export-ready claim. doctor retrieves an installed/active full-AutoCAD config from a process that accepts and detects zero error local, while doctor does not commitments to paid or test access. Ob eine native Instandhaltung zugleich bindet auf eine Source-Blank-DXF, off AutoCAD nur eine separate Laufzeit-DWG: deren Behalt Abgleich einen gespeicherten Hash belegt und die direkte Instandsvergleich von einem DXF→DWG→DXF-Strom Vergleich liefert. TrueView does not satisfy this barrier.
Siehe docs/PRODUCT_BOUNDARY.md, bevor Sie Fähigkeiten geltend machen. Die portable DXF-3D ist ein Prüfungsergebnis; Auch eine engineering-3D-Master-DWG enthält erfrischende, messbare 3DSOLID-Objekte, die von voll AutoCAD aus quellenbasierter Evidenz erzeugt werden.
Apache-2.0. Das COM-/MCP-Design wurde vom Apache-2.0-Projekt multiCAD-mcp Inform; see NOTICE.
Apply a bounded, traceable edit to the active managed AutoCAD work copy. Deletion is limited to provably agent-owned entities; source-backed text updates require provenance.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| params | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true, so the description is not required to restate that. It adds value by disclosing limits on destructive actions: deletion is restricted to agent-owned entities and source-backed text updates require provenance. This gives operational constraints beyond the annotation, though it doesn't detail error/rollback behavior.
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 two sentences with zero filler. It front-loads the core purpose and then delivers key constraints, making it both concise and well-ordered. Every word earns its place.
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 six distinct actions and an unstructured params object, the description is far too brief. It only hints at two use-case constraints but says nothing about how to invoke each action, what params to pass, or what the result looks like. The high complexity demands significantly more explanation than given.
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 0% and the description mentions no parameter details whatsoever. The params object is unstructured (additionalProperties: true) with six possible actions, yet the description provides no guidance on what each action expects or how to construct params, leaving the agent entirely without parameter semantics.
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 a specific verb 'apply edit' and a specific resource 'active managed AutoCAD work copy'. It further distinguishes itself from sibling tools (query, export, session, project) by being the modification tool, and it adds constraints about deletion and source-backed text updates, making its scope 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?
Usage is implied by the tool name and the context of sibling tools—this is obviously the edit tool for the warehouse CAD work copy. However, the description does not explicitly state when to use it versus alternatives, nor does it mention when not to use it, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the managed work copy or build a native 3DSOLID DWG. All paths remain under the authorized root; native solids require source-verified footprint, height, and elevation.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| params | No | ||
| project_file | No | User-selected absolute or current-workspace project.yaml path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full responsibility for behavioral disclosure. It mentions path restrictions and prerequisites for native solids, but does not disclose whether the operation modifies data, creates files, has side effects, or requires specific permissions. For an export tool, it is likely to create files, but this is not stated. The description adds some transparency about constraints but lacks detail on side effects and 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 two short sentences with no filler. It efficiently states the core function and key constraints, front-loading the action and important prerequisites. Every word adds value, making it appropriately concise and well-structured.
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 has a nested params object, an action enum with five values, and no output schema, the description is insufficient. It does not explain the purpose of each action, what parameters to pass for each, or what the return format will be. While it notes path restrictions and prerequisites, it omits crucial operational details needed for correct invocation, especially for the 'params' object which is entirely opaque.
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 33% (only project_file has a description). The tool description does not explain the 'action' enum values or the structure of the 'params' nested object. It vaguely references requirements for native solids (footprint, height, elevation) but does not map these to specific parameters. With low schema coverage, the description fails to compensate, leaving agents uncertain about how to fill the params object and what each action entails.
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: exporting the managed work copy or building a native 3DSOLID DWG. It specifies two primary modes and distinguishes this from sibling tools (warehouse_project, warehouse_cad_session, etc.) as an export operation. However, it does not enumerate all action enum values (data, dxf, pdf, snapshot), leaving some ambiguity about the full scope of export types.
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 some context for when to use the tool, indicating that native solids require source-verified footprint, height, and elevation, and that all paths are restricted to the authorized root. However, it does not explicitly contrast with alternative tools or provide explicit when-to-use versus when-not-to-use guidance. The conditions given are more about prerequisites than about choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List, inspect, highlight, measure, or compare entities in the active managed AutoCAD work copy. Geometry measurements remain calculations, not verified business facts.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| params | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a meaningful caveat beyond the readOnlyHint annotation: 'Geometry measurements remain calculations, not verified business facts.' This warns the agent that measurement results are not authoritative, which is valuable. However, it does not elaborate on behaviors for each action (e.g., whether 'highlight' changes the UI selection state) or other side effects beyond the read-only 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 two sentences with no waste. The first sentence front-loads the core operations and target, and the second delivers an important caveat. Both sentences earn their place and the structure is clear.
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 five distinct actions and an open-ended params object, the description is too sparse. It does not define what each action does, what parameters they expect, or what the return looks like (no output schema). It also does not clarify prerequisites like an active session or what 'managed work copy' means. The description is incomplete for an agent to call this tool correctly without further inference.
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 0%, and the description does not compensate. It lists verbs that roughly correspond to the action enum (e.g., 'inspect' vs 'get', 'highlight' vs 'select') but does not explain each action's purpose or the expected structure of the params object. The generic params is left entirely unexplained, and the wording mismatch between the description and enum values adds confusion.
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: to list, inspect, highlight, measure, or compare entities in the active managed AutoCAD work copy. The verb set is specific and distinguishes it from sibling tools like warehouse_cad_edit (modification) and warehouse_cad_export (export). The read-only nature is implied by the verbs and consistent with the annotation.
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 guidance on when to use this tool versus the sibling tools. The description only mentions the active managed AutoCAD work copy, but does not explain when to choose query over edit/export/session/project. The name 'query' suggests a read-only role, but the description lacks any 'use this when...' or 'use X instead' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to writable full AutoCAD and manage exactly one automatically-created work copy. Never opens the customer source as a write target; TrueView is rejected. Shutdown can quit only a document-free AutoCAD instance launched by this Agent.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| params | No | ||
| project_file | No | User-selected absolute or current-workspace project.yaml path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose key safety behaviors: it never opens the customer source as a write target, rejects TrueView, and shutdown can only quit a document-free instance launched by this Agent. These are valuable but do not cover the full range of actions or their side effects, so partial 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 description is three sentences with no fluff. The core purpose is front-loaded, followed by key constraints. It is efficient and avoids 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?
For a tool with 7 actions, a nested params object, and no output schema, the description is insufficient. It does not explain what any of the actions do, what parameters they need, or what the return looks like. The agent is left guessing on crucial execution details, so completeness is low.
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 only 33% — only project_file is described in the schema. The description adds no information about the 'action' enum values or the 'params' object (which is untyped with additionalProperties true). The agent has no idea what each action requires or how to structure params, and the description fails to compensate for this low coverage.
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 states the tool connects to writable full AutoCAD and manages 'exactly one automatically-created work copy', giving a specific verb and resource. It also clarifies it rejects TrueView and never writes to the customer source, which helps distinguish it from other CAD tools. However, it does not explicitly name sibling tools to differentiate, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides constraints (never write to source, TrueView rejected, shutdown limits) but gives no guidance on when to choose this tool over the sibling tools like warehouse_cad_edit or warehouse_cad_query. There is no explicit 'use this when...' or 'use that instead...' guidance, leaving the agent to infer the tool's scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate, audit, rebuild, verify, package, or control one declared warehouse CAD project. Long jobs are single-worker and return job_id. Audit output is not an independent acceptance denominator by itself.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| job_id | No | ||
| params | No | ||
| project_file | No | User-selected absolute or current-workspace project.yaml path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that long jobs are single-worker and that audit output is not an independent acceptance denominator, which are useful caveats. However, it omits other behavioral aspects like side effects, permission requirements, or reversibility, leaving transparency incomplete.
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 concise (two sentences) and front-loads the key actions. It avoids unnecessary words, but the brevity somewhat undermines clarity. The structure is acceptable for a short description, though it could benefit from a brief explanation of the actions.
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 complexity (10-action enum, nested params object, no output schema), the description is far from complete. It does not describe each action's purpose, the format of params, or expected outcomes. The note about job_id and audit output provides some context, but an agent would still need significant external knowledge to invoke this 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?
The input schema covers only 25% of parameters (only project_file has a description). The description does not explain the 'action' enum values, the purpose of job_id, or the 'params' object. It mentions job_id in passing but provides no guidance on how to construct or interpret it. This is insufficient for an agent to correctly fill parameters, especially given the low schema coverage.
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 lists specific verbs (validate, audit, rebuild, verify, package, control) acting on 'one declared warehouse CAD project', giving a clear resource and a set of operations. It distinguishes this tool from siblings that handle sessions, queries, edits, and exports by focusing on project-level actions, though the broad action list makes the primary purpose less crisp than a single-verb description.
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 indicate when to use this tool versus the sibling tools (warehouse_cad_session, warehouse_cad_query, etc.) or when not to use it. The only usage hint is that long jobs are single-worker and return job_id, but there is no explicit guidance on scenario selection or alternative routing.
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.
v0.1.0warehouse_cad_editwarehouse_cad_exportwarehouse_cad_querywarehouse_cad_sessionwarehouse_projectScored across 5 tools
Each tool targets a distinct level: project management, session management, querying, editing, and exporting. No two tools overlap in purpose, making selection unambiguous.
All tools share the 'warehouse_' prefix, and four of five follow the 'warehouse_cad_' pattern. The sole exception, 'warehouse_project', still fits the broad naming scheme but lacks the 'cad_' segment, a minor inconsistency.
With only 5 tools, the set is tightly focused and each tool covers a major capability area. This is an ideal scope for a CAD agent, avoiding bloat while remaining useful.
The tools cover the full workflow from project validation/rebuild, session control, query, edit, to export. Minor gaps exist (e.g., no explicit import or undo), but the core lifecycle is well supported.
MCP CAD services; bundles with SmartScale (measure to CAD).
Agent-first CAD: editable .kcad.ts source, deterministic review, OpenCASCADE kernel.
Headless CAD engine & MCP server for 2D/3D drafting, solids, DXF/SVG export, and automation.
Read and edit the Revit 2024–2027 model on your PC. Needs the free Revit MCP add-in.
