warehouse-cad-agent — это Windows-first плагин Codex и Python-движок для отслеживаемых циклов работы со складским CAD:
аудит каждой сущности пространства модели в объявленном DXF или в DWG, чья read-DXF конвертация имеет совпадающую хэш-квитанцию;
отделение видимого оборудования от конструкции без молчаливого принятия неразрешённых кандидатов;
создание одного самодостаточного Markdown-реестра оборудования;
восстановление редактируемого 2D CAD только из пустого CAD и этого реестра;
создание ограниченного доказательствами переносимого 3D и нативного 3DSOLID AutoCAD, когда существуют полные подтверждённые исходными данными сведения о footprint, высоте и отметке;
возможность Агенту просматривать и редактировать автоматически созданную рабочую копию AutoCAD через пять ограниченных инструментов MCP.
Проект намеренно не выводит отсутствующие идентичность устройства, высоту, отметку, направление потока, порты или геометрию производителя. Протокольное рукопожатие, скриншот, проверка существования файла или количество выбранных выходных данных не считаются доказательством полноты запрошенного CAD-артефакта.
Этот репозиторий содержит только универсальный движок, плагин, навык, MCP-мост, синтетические фикстуры и код проверки. Чертежи клиентов, имена клиентов, исходные хэши, частные профили классификации и доказательства поставки принадлежат отдельному частному интеграционному репозиторию.
Related MCP server: AgentCAD
Требования: Python 3.11+ и, опционально, полный AutoCAD с COM-автоматизацией для живого редактирования и нативных твердотельных объектов DWG. Autodesk DWG TrueView не является доступным для записи временем выполнения AutoCAD.
Управляемые открытия AutoCAD временно используют DWGCHECK=0 только вокруг Documents.Open, ожидают, пока AutoCAD не станет бездействующим после открытия, затем восстанавливают и проверяют точное предыдущее значение. Это подавляет только предупреждение о непроизводителе Autodesk, сохраняя диалог ошибок повреждения AutoCAD; это не объявляет чертёж действительным.
Создание живых заметок проверки никогда не повторяет неидемпотентный вызов AddText. Если AutoCAD сообщает об ошибке вызова после создания чего-либо, мост использует снимок дескрипторов пространства модели до записи, а также тип, вставку и высоту, чтобы восстановить только один уникально атрибутируемый новый текстовый объект. Заметка, её слой и зарегистрированное приложение принадлежат одной транзакции отмены. Известные поля записываются не более одного раза и считываются обратно. Если неполный результат изменил снимок дескриптора/слоя/зарегистрированного приложения, мост запрашивает одну отмену и проверяет все три набора; если снимок никогда не менялся, он не отменяет и не заявляет об откате. Любое недоказанное восстановление сохраняет управляемую рабочую копию с структурированной ошибкой частичного редактирования.
Принятие сохранённых/закрытых/повторно открытых файлов может использовать новый процесс AutoCAD, запущенный Агентом. Действие сеанса shutdown является fail-closed: оно требует отсутствия управляемого сеанса, отсутствия контрольного чертежа, нулевого количества открытых документов и подтверждённого выхода точного процесса, привязанного к окну приложения. Его опциональный запасной вариант force_if_graceful_timeout=true ограничен этим процессом, запущенным Агентом: после того как один корректный Application.Quit истекает по тайм-ауту, мост должен повторно подтвердить, что AutoCAD бездействует с нулевым количеством документов, прежде чем завершить уже привязанный дескриптор процесса Windows один раз. Он никогда не завершает и не прекращает работу приложения 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.yamlМанифест маркетплейса репозитория Codex — это .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» и свежий вызов doctor Codex/MCP были проверены локально. На одном точном синтетическом DWG установленный плагин также прошёл реальное создание/запрос/откат/сохранение в AutoCAD 2027 Trial, а также сверку повторного открытия в новом процессе. Один точный, частный, привязанный к хэшу складской DWG + набор исходных данных реестра оборудования дополнительно прошёл нативную генерацию 3DSOLID, сохранение финального DWG, повторное открытие ObjectDBX с совпадающей версией, сверку идентичности/геометрии на уровне записей Агента и сверку финальной структуры в реальном AutoCAD 2027 Trial. Это узкие результаты для конкретного набора исходных данных, а не заявление о произвольном DWG, моделях производителей, BIM или готовности к производству. doctor отличает установленную/активную полную идентичность AutoCAD от процесса, который в данный момент достаточно бездействует для приёма автоматизации; он не делает вывод о платной или пробной лицензии. Когда спецификация нативного твердотельного объекта остаётся привязанной к исходному пустому DXF, AutoCAD открывает только отдельно предоставленный рабочий DWG, чья квитанция о преобразовании связывает оба хэша и доказывает сравнение структуры DXF→DWG→DXF с нулевым расхождением в потоковом режиме. TrueView не удовлетворяет этому условию.
См. docs/PRODUCT_BOUNDARY.md перед заявлениями о возможностях. Переносимый DXF 3D является производным аудита; нативный инженерный 3D-мастер — это DWG, содержащий повторно открытые, измеримые объекты 3DSOLID, созданные полным AutoCAD на основе подтверждённых исходных данных.
Apache-2.0. Дизайн COM/MCP был разработан с учётом проекта multiCAD-mcp под лицензией Apache-2.0; см. 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.
