{
  "markdown": "# DWG MCP Server\n\nDWG and DXF file format access for AI via MCP.\n\nConnect DWG and DXF files to Claude, ChatGPT, Codex, Cursor, and other MCP clients.\nDWG MCP Server provides structured access to DWG data so AI can understand and\nreason about drawings. Source files remain read-only; supported entity\nproperties can be changed in memory for inspection and rendering.\n\n## Quick Start\n\nUse DWG MCP Server from the MCP client of your choice.\nThe npm package downloads the matching native build from GitHub Releases on\nfirst use, verifies its SHA-256 checksum, caches it, and runs it directly.\nDocker and a separate Python installation are not required.\n\nIf your MCP client, AI agent, or test harness does not support MCP roots, set\n`DWG_MCP_ALLOWED_ROOTS` to the folders that should be accessible.\n\n### Codex\n\n```bash\ncodex mcp add dwg-mcp \\\n  --env DWG_MCP_ALLOWED_ROOTS=\"$HOME\" \\\n  -- npx -y @dmytro-prototypes/dwg-mcp-server\n```\n\nCodex does not currently provide MCP client roots to stdio MCP servers. Configure\nexplicit allowed roots for the folders that contain your drawings.\n\n### Claude\n\n```bash\nclaude mcp add --scope user --transport stdio dwg-mcp -- npx -y @dmytro-prototypes/dwg-mcp-server\n```\n\nClaude Code provides MCP roots, so no extra path variable is usually needed.\n\n### Cursor\n\n```json\n{\n  \"mcpServers\": {\n    \"dwg-mcp\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"@dmytro-prototypes/dwg-mcp-server\"]\n    }\n  }\n}\n```\n\n## Exposed Tools\n\n| Tool | Purpose |\n| --- | --- |\n| `dwg.list_roots` | List folders available for DWG access. |\n| `dwg.open_file` | Open a DWG or DXF from an available folder and return a `documentId`. |\n| `dwg.close_file` | Close an opened document and release its worker process. |\n| `dwg.list_types` | List the globally supported DWG types known to the backend. |\n| `dwg.list_file_types` | List only the types that are present in a specific opened DWG. |\n| `dwg.describe_type` | Describe a supported type, including readable and writable properties and its default projection. |\n| `dwg.get_objects` | Fetch specific objects by handle, preserving the requested order and reporting missing handles. |\n| `dwg.query_objects` | Query objects with filters, scopes, relation traversal, sorting, projection, and pagination. |\n| `dwg.set_entity_properties` | Change properties marked writable on one entity in memory. Changes are discarded when the document closes. |\n| `dwg.list_render_views` | List renderable model space, paper-space layouts, and layout viewports. |\n| `dwg.render_view` | Render a complete view or selected drawing region as PNG or SVG. |\n\nA typical flow is:\n\n1. Discover available folders with `dwg.list_roots`.\n2. Open a file from one of those folders with `dwg.open_file`.\n3. Inspect supported or file-local types with `dwg.list_types`, `dwg.list_file_types`, or `dwg.describe_type`.\n4. Fetch known handles with `dwg.get_objects` or search the drawing with `dwg.query_objects`.\n5. Optionally change properties reported as writable with `dwg.set_entity_properties`.\n6. Discover and render drawing views with `dwg.list_render_views` and `dwg.render_view`.\n7. Close the session with `dwg.close_file`, discarding in-memory changes.\n\n## Architecture\n\n### Runtime model\n\nIn the packaged deployment, DWG MCP Server is a standalone native application\nbuilt for the host operating system.\nThe Python host exposes the MCP tools, validates file access, and manages document sessions.\n\nEach `dwg.open_file` call starts a dedicated Rust `dwg-worker` process for that DWG and returns a host-side `documentId`.\nAll later file-scoped calls use that document id.\n`dwg.close_file` terminates the worker for that session.\n\n### Worker and query model\n\nThe Rust worker speaks newline-delimited JSON over stdin and stdout.\nWhen it opens a DWG through LibreDWG, it first builds an in-memory indexed document.\nThat upfront indexing step is central to the design: the server pays the cost once when the file is opened, then answers later requests against the index instead of rescanning the DWG each time.\n\nThe indexed model stores object handles, kinds, type names, generic types, summary and full properties, and derived block, layout, and space membership.\nIt also stores supported type metadata such as aliases, default projections, and property definitions.\n\nWhen you request full object records, responses also include that derived membership under `extendedData`, including container block, layout, and model or paper space when known.\n\n`dwg.get_objects` is direct lookup by handle.\n`dwg.query_objects` runs over indices for handle, type, generic type, kind, exact property values, block, layout, and space, then applies filters, scopes, relation traversal, sorting, projection, and pagination.\nThis is what makes queries over blocks, layers, layouts, references, and related objects practical on an opened drawing.\n\n`dwg.set_entity_properties` validates writes against the type catalog, updates\nthe native LibreDWG document, rebuilds the index, and invalidates the cached\nrendering scene. Block-reference insertion points use OCS coordinates, block\nscaling rules are enforced, and attributed block references are rejected until\ntheir owned attributes can be transformed safely. The tool does not save or\noverwrite the source file.\n\nThe worker lazily compiles a separate rendering scene on the first render call.\nIt expands block references and generated dimension blocks, draws common 2D\ngeometry, text, MTEXT, hatch contours, and approximated point-list entities,\nand composes paper-space layouts through their viewports. SVG is the canonical\nrender output; PNG is rasterized from the same SVG in memory. Render responses\ninclude coverage diagnostics for generated-block fallbacks and unsupported\nentity types. Automatic fit rejects extreme sparse extents, WIPEOUT boundaries\nmask earlier geometry, and explicit regions allow bounded rendering of dense\nviews. See [`docs/rendering.md`](docs/rendering.md) for the protocol and\nrendering model.\n\n### Access and packaging\n\nDWG and DXF files must be opened from roots listed by `dwg.list_roots`. The server first\nasks the MCP client for roots. If the client, AI agent, or test harness does not\nsupport MCP roots, configure explicit allowed roots:\n\n```bash\npython3 -m dwg_mcp_server --allowed-root \"$HOME/Downloads\"\n```\n\nor:\n\n```bash\nDWG_MCP_ALLOWED_ROOTS=\"$HOME/Downloads;$HOME/Documents/dwg\" \\\npython3 -m dwg_mcp_server\n```\n\n`DWG_MCP_ALLOWED_ROOTS` is an authorization fallback for clients without roots.\nIt should be a semicolon-separated list of absolute directories.\n\nOfficial releases contain a standalone MCP host, the statically linked Rust\nworker, and the LibreDWG schema files needed at runtime.\n\n### Native platforms\n\nGitHub Actions builds and tests these release artifacts on their native runners:\n\n| System | CPU | Rust target |\n| --- | --- | --- |\n| macOS | Apple Silicon | `aarch64-apple-darwin` |\n| Windows | Intel or AMD 64-bit | `x86_64-pc-windows-gnu` |\n| Linux | Intel or AMD 64-bit | `x86_64-unknown-linux-gnu` |\n| Linux | ARM 64-bit | `aarch64-unknown-linux-gnu` |\n\n`x64`, `x86_64`, and `AMD64` name the same CPU architecture; the Windows and\nLinux artifacts work on both Intel and AMD processors.\n\n## Build and Test From Source\n\nLocal source builds use the vendored `third_party/libredwg` submodule by default.\n\n### Prerequisites\n\n- Rust toolchain\n- Python 3.11 or newer\n- autotools for local LibreDWG builds on macOS or Linux (`autoreconf`, `aclocal`, `automake`, `autoconf`, `make`)\n\n### Bootstrap\n\n```bash\ngit submodule update --init --recursive\nbash scripts/build-libredwg.sh\n```\n\n### Build and test\n\n```bash\ncargo test --workspace\nbash scripts/run-e2e-tests.sh\n```\n\n### Run the MCP host locally\n\nThe Python host looks for `dwg-worker` under `target/release` or `target/debug`.\nIf you want a release build explicitly:\n\n```bash\ncargo build -p dwg-worker --release\n```\n\nThen run the MCP host:\n\n```bash\nPYTHONPATH=server/src python3 -m dwg_mcp_server\n```\n\nIf the worker binary lives somewhere else, set `DWG_WORKER_BIN` to that executable.\n\n### Publish a native release\n\n1. Set the same version in `npm/package.json`, `server.json`, and the Claude\n   extension manifest when applicable.\n2. Configure npm trusted publishing for `.github/workflows/native-release.yml`.\n3. Push the matching `v<version>` tag.\n\nThe `Native Release` workflow builds and tests all four platforms, creates the\nGitHub Release with checksum files, and then publishes the npm launcher. A\nmanual workflow run can build one selected platform or all four as downloadable\nActions artifacts without publishing.\n\n### Clean rebuild\n\nRemove local Rust and Python build artifacts:\n\n```bash\nbash scripts/clean-build-artifacts.sh\n```\n\nTo also wipe the host LibreDWG build under `third_party/libredwg`:\n\n```bash\nbash scripts/clean-build-artifacts.sh --with-libredwg\n```\n\n## Official MCP Registry\n\nRegistry metadata lives in `server.json` under the GitHub-authenticated name\n`io.github.dimitrovakulenko/dwg-mcp-server`.\n\nBefore publishing a new registry version:\n\n1. Publish the matching npm package version from `npm/`.\n2. Confirm `npm/package.json` contains the same `mcpName` as `server.json`.\n3. Run the manual `Publish MCP Registry` GitHub Actions workflow, or run:\n\n```bash\nmcp-publisher login github\nmcp-publisher publish\n```\n\nThe registry validates the published npm package, so `server.json` must point to\nan npm version that already exists on the public npm registry.\n\n## License\n\nThis project is licensed under the GNU General Public License v3.0.\nSee `LICENSE` for the full license text.\n",
  "bytes": 9567,
  "sha": "68d92b74656138615ae477b690432992ce4a0f6aac5fd97b509c643cbbb9fb99",
  "repo_slug": "dimitrovakulenko/dwg-mcp-server",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_dimitrovakulenko_dwg_mcp_serve_f3da25d4/readme"
}