warehouse-cad-agent는 Windows 우선 Codex Plugin이자 추적 가능한 창고 CAD 왕복 작업을 위한 Python 엔진입니다:
선언된 DXF 또는 읽기용 DXF 변환에 일치하는 해시 영수증이 있는 DWG의 모든 모델 공간 엔티티를 감사합니다;
미해결 후보를 조용히 수용하지 않고 가시 장비를 구조물과 분리합니다;
자체 포함된 Markdown 장비 원장 하나를 작성합니다;
빈 CAD와 해당 원장만으로 편집 가능한 2D CAD를 재구축합니다;
증거가 제한된 휴대용 3D를 생성하고, 완전한 소스 기반 풋프린트, 높이, 표고 증거가 있을 때 기본 AutoCAD 3DSOLID를 생성합니다;
Agent가 다섯 개의 제한된 MCP 도구를 통해 자동 생성된 AutoCAD 작업 복사본을 검사하고 편집할 수 있게 합니다.
이 프로젝트는 의도적으로 누락된 장치 ID, 높이, 표고, 흐름 방향, 포트 또는 제조업체 지오메트리를 추론하지 않습니다. 프로토콜 핸드셰이크, 스크린샷, 파일 존재 확인 또는 출력 선택 개수는 요청된 CAD 산출물이 완전하다는 증거로 취급되지 않습니다.
이 저장소에는 일반 엔진, Plugin, Skill, MCP 브리지, 합성 픽스처 및 검증 코드만 포함되어 있습니다. 고객 도면, 고객 이름, 소스 해시, 비공개 분류 프로필 및 납품 증거는 별도의 비공개 통합 저장소에 속합니다.
Related MCP server: AgentCAD
요구 사항: Python 3.11+ 및 선택적으로 라이브 편집과 기본 DWG 솔리드를 위한 COM 자동화가 포함된 전체 AutoCAD. Autodesk DWG TrueView는 쓰기 가능한 AutoCAD 런타임이 아닙니다.
관리되는 AutoCAD 열기는 Documents.Open 주변에서만 임시로 DWGCHECK=0을 사용하고, 열린 후 AutoCAD가 유휴 상태가 될 때까지 대기한 다음 정확한 이전 값을 복원하고 검증합니다. 이는 AutoCAD의 손상 오류 대화상자는 유지하면서 비 Autodesk 생성자 경고만 억제합니다. 도면이 유효하다고 선언하지는 않습니다.
라이브 검토 메모 생성은 비멱등적 AddText 호출을 재시도하지 않습니다. AutoCAD가 무언가를 생성한 후 호출 실패를 보고하면, 브리지는 쓰기 전 모델 공간 핸들 스냅샷과 유형, 삽입점, 높이를 사용하여 고유하게 귀속될 수 있는 새 텍스트 엔티티 하나만 복구합니다. 메모, 해당 레이어 및 등록된 응용 프로그램은 하나의 실행취소 트랜잭션에 속합니다. 알려진 필드는 각각 최대 한 번 작성되고 다시 읽힙니다. 불완전한 결과로 핸들/레이어/등록된 응용 프로그램 스냅샷이 변경된 경우, 브리지는 실행취소를 한 번 요청하고 세 집합을 모두 검증합니다. 스냅샷이 변경되지 않은 경우 실행취소하거나 롤백을 주장하지 않습니다. 입증되지 않은 복구는 구조화된 부분 편집 오류와 함께 관리되는 작업 복사본을 보존합니다.
저장/닫기/다시 열기 승인은 새 Agent 시작 AutoCAD 프로세스를 사용할 수 있습니다. shutdown 세션 작업은 실패 시 폐쇄(fail-closed) 방식입니다. 관리되는 세션 없음, 제어 도면 없음, 열린 문서 0개, 응용 프로그램 창에 바인딩된 정확한 프로세스의 종료 확인이 필요합니다. 선택적 force_if_graceful_timeout=true 폴백은 해당 Agent 시작 프로세스로 제한됩니다. 정상적인 Application.Quit이 한 번 시간 초과된 후, 브리지는 이미 바인딩된 Windows 프로세스 핸들을 한 번 종료하기 전에 AutoCAD가 문서 0개로 유휴 상태인지 다시 확인해야 합니다. Agent가 단지 연결만 한 AutoCAD 응용 프로그램은 절대 종료하거나 끝내지 않습니다.
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.yamlCodex 저장소 마켓플레이스 매니페스트는 .agents/plugins/marketplace.json입니다. 복제된 저장소를 로컬 마켓플레이스로 등록하고, 플러그인을 설치한 다음, 새 Codex 스레드를 시작하십시오:
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-agent새 스레드에서 $warehouse-cad-agent를 호출하십시오. 마켓플레이스는 ON_USE 인증을 사용합니다. 첫 번째 로컬 MCP 사용을 대화형으로 승인하십시오. approval=never로 구성된 비대화형 세션은 다섯 개의 도구를 발견하지만, 해당 호출이 명시적으로 승인되지 않는 한 호출을 거부해야 합니다.
project.yaml은 실행 허용 목록입니다. 별개의 source.read_dxf는 source.read_conversion_receipt를 포함해야 합니다. 미해결 객체는 바인딩된 source.resolution.inventory와 source.resolution.ledger를 통해서만 분류될 수 있습니다. 제품 감사는 파일을 열거하지만, 그 자체로 독립적인 고객 승인 분모는 아닙니다.
빈 CAD와 Markdown은 서로 교환 가능한 유효 파일로 취급되지 않습니다. 빈 파일에는 포함된 프로젝트/소스 바인딩이 있고, Markdown 원장은 정확한 빈 파일 SHA-256도 바인딩하며, 모든 재구축은 출력을 쓰기 전에 불일치하거나 수정된 쌍을 거부합니다. 기본 솔리드 사양을 생성하는 고객 어댑터는 동일한 정확한 빈 파일 규칙을 사용하고 이전 소스 원장 승인 대상을 현재 기본 CAD 제품 대상과 분리하여 유지합니다.
합성 빈 파일 + Markdown + 격리된 2D + 휴대용 3D 경로와 새로운 Codex/MCP doctor 호출이 로컬에서 실행되었습니다. 정확히 하나의 합성 DWG에서 설치된 Plugin은 실제 AutoCAD 2027 Trial 생성/쿼리/롤백/저장과 새 프로세스 다시 열기 조정도 통과했습니다. 정확히 하나의 비공개로 보유된 해시 바인딩 창고 DWG + 장비 원장 소스 세트는 추가로 기본 3DSOLID 생성, 최종 DWG 저장, 버전 일치 ObjectDBX 다시 열기, 레코드 수준 Agent ID/지오메트리 조정, 실제 AutoCAD 2027 Trial에서의 최종 구조 조정을 통과했습니다. 이는 좁은 소스 세트 결과이지 임의 DWG, 제조업체 모델, BIM 또는 프로덕션 준비 완료 주장이 아닙니다. doctor는 설치/활성 전체 AutoCAD ID를 자동화를 수용할 만큼 현재 유휴 상태인 프로세스와 구분합니다. 유료 또는 평가판 자격을 추론하지 않습니다. 기본 솔리드 사양이 소스 빈 DXF에 바인딩된 상태로 유지되면, AutoCAD는 변환 영수증이 두 해시를 모두 바인딩하고 제로 불일치 스트리밍 DXF→DWG→DXF 구조 비교를 입증하는 별도로 제공된 런타임 DWG만 엽니다. TrueView는 해당 게이트를 충족하지 못합니다.
기능 주장을 하기 전에 docs/PRODUCT_BOUNDARY.md를 참조하십시오. 휴대용 DXF 3D는 감사 파생물입니다. 기본 엔지니어링 3D 마스터는 소스 기반 증거로부터 전체 AutoCAD가 생성한 다시 열고 측정 가능한 3DSOLID 객체를 포함하는 DWG입니다.
Apache-2.0. COM/MCP 설계는 Apache-2.0 multiCAD-mcp 프로젝트에서 참고했습니다. 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.
