kernelCAD

Convert Drawing to CAD

drawing_to_cad

Use this when the reference for a part is a 2D engineering drawing PDF (orthographic views with dimensions), not a photo. Deterministic, no vision model: reads the vector linework (stroke width, dash) and positioned text; classifies visible / hidden / center / dimension / extension lines; reads the title block scale, units and projection symbol; identifies front / top / side views by projection alignment (third- or first-angle); ties dimension text to its lines (⌀, R, 4×, ±, THRU, depth). Dimension values win over measured lengths. Rebuilds the part as the view silhouette extruded by the depth an orthogonal view shows, or a turned part revolved from its half-silhouette, plus holes from ⌀ circles with THRU or hidden-line depth. Returns script — a .kcad.ts with role-named params (width, thickness, holeDia, hole1X, dia1, step1Length …) — and ledger, an assumption ledger where stated dimensions are visible, symmetry-derived positions inferred, defaults assumed and an unstated depth missing; a dimension that disagrees with the linework keeps its value and records the disagreement as an open fact. With verify (default) the script is evaluated, re-projected through the svg-drawing view stage and compared: fidelity.verdict is match | partial | mismatch | failed with per-axis extents, hole diameters and per-view silhouette IoU. Pass out to write the script and its <stem>.ledger.json (resolve open facts with resolve_assumptions, then set_param). A scanned (raster-only) page fails with reference.drawing.raster-only — use trace_from_image for those. Hosted: give the file as an https:// URL, a data: URI (base64, max 25 MB) or "asset:" from request_upload (when the file is on the user's device).

Input Schema

Name	Required	Description
`out`	No	Write the emitted script here (a .kcad.ts path); the ledger is written beside it as <stem>.ledger.json.
`page`	No	1-based page to read. Default 1.
`path`	No	Path to the drawing PDF on the machine running kernelCAD. Hosted server: pass an https:// URL, a data: URI, or "asset:<id>" from request_upload — not a path on your machine.
`intent`	No	The user's request in one sentence, in the user's own words and language (e.g. 'M4 bracket for a 25 mm tube, print on Bambu A1'). Helps kernelCAD improve; leave out personal data.
`verify`	No	Evaluate the rebuilt part and compare it with the drawing. Default true.
`pdfBase64`	No	The PDF inline, base64-encoded. Use this instead of `path` against a hosted kernelCAD server.
`projection`	No	Override the projection angle read from the sheet (default: projection symbol or note, else third-angle).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 11, 2026

removedOutput schema / properties

Removed value: -{
-  "diagnostics": {
-    "items": {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    "type": "array"
-  },
-  "fidelity": {
-    "additionalProperties": true,
-    "description": "{ verdict: match | partial | mismatch | failed, extents, holes, silhouettes, reasons } from evaluating and re-projecting the script.",
-    "type": "object"
-  },
-  "ledger": {
-    "additionalProperties": true,
-    "description": "Assumption ledger: { facts, unresolvedCount }; facts are visible / inferred / assumed / missing, disagreements recorded on the fact.",
-    "type": "object"
-  },
-  "ledgerPath": {
-    "description": "Where the ledger was written (when `out` was given); pass it to resolve_assumptions.",
-    "type": "string"
-  },
-  "ok": {
-    "type": "boolean"
-  },
-  "page": {
-    "type": "integer"
-  },
-  "pageCount": {
-    "type": "integer"
-  },
-  "params": {
-    "description": "Role-named params declared by the script: { name, value, description }.",
-    "items": {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    "type": "array"
-  },
-  "reconstruction": {
-    "additionalProperties": true,
-    "description": "{ kind: extrude | revolve, profileView, axis, holeCount, extents }.",
-    "type": "object"
-  },
-  "script": {
-    "description": "The emitted .kcad.ts source.",
-    "type": "string"
-  },
-  "scriptPath": {
-    "description": "Where the script was written (when `out` was given).",
-    "type": "string"
-  },
-  "sheet": {
-    "additionalProperties": true,
-    "description": "{ widthMm, heightMm, scale: { text, sheetPerModel, source }, units, projection } read off the sheet.",
-    "type": "object"
-  },
-  "views": {
-    "description": "Identified orthographic views: { name, bboxMm, identifiedBy, label? }.",
-    "items": {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    "type": "array"
-  }
-}

removedOutput schema / required

Removed value: -[
-  "ok",
-  "views",
-  "params",
-  "ledger",
-  "diagnostics"
-]

Changed2 schema fields changedOct 3, 2026

addedInput schema / properties / intent

Added value: +{
+  "description": "The user's request in one sentence, in the user's own words and language (e.g. 'M4 bracket for a 25 mm tube, print on Bambu A1'). Helps kernelCAD improve; leave out personal data.",
+  "maxLength": 2000,
+  "type": "string"
+}

changedInput schema / properties / path / description

Previous value: -"Path to the drawing PDF on the machine running kernelCAD."New value: +"Path to the drawing PDF on the machine running kernelCAD. Hosted server: pass an https:// URL, a data: URI, or \"asset:<id>\" from request_upload — not a path on your machine."

AddedSep 21, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare the generic mutation/open-world profile, and the description adds substantial context beyond them: it is deterministic with no vision model, dimension text overrides measured lengths, disagreements are preserved as open facts, the raster-only failure code is named, and hosting constraints (https URL, data: URI max 25 MB, asset:<id>) are given. The only gap is that it doesn't say what `script` looks like structurally or how expensive the verify re-projection pass is, which matters for a non-idempotent, non-read-only tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The routing condition is front-loaded in the first sentence and every subsequent sentence adds a distinct fact (line classification, dimension precedence, output artifacts, verify verdicts, failure mode, hosting). It is, however, a single very dense paragraph with no breaks, and a few clauses (e.g. the full list of role-named params) could be trimmed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 7 parameters, an output schema, and a verification pipeline, the description covers input contract, internal behavior, failure mode, downstream resolution workflow, and the meaning of the returned ledger states. Nothing an agent needs to call this correctly or to interpret the result is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so this is baseline-plus: the description explains the side effect of `out` (ledger written as <stem>.ledger.json beside it) and the default semantics of `verify`, and reiterates the hosted-vs-local input contract for `path`/`pdfBase64`/asset. It doesn't clarify `page` or when to override `projection`, but the value-add over the schema is real.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (convert a 2D engineering drawing PDF into a parametric .kcad.ts script) and immediately distinguishes it from the sibling trace_from_image by input type ('drawing PDF ... not a photo'). The mechanism is spelled out (vector linework, dimension-to-line association, extrude/revolve), so an agent knows exactly what class of operation this is.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with an explicit when-to-use clause keyed to the input being an orthographic PDF, names the alternative for the excluded case ('A scanned (raster-only) page ... use trace_from_image'), and closes the loop on follow-up tools (resolve_assumptions then set_param for open facts). No inference is required to route correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All kernelCAD tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.