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.

Input Schema

TableJSON 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.
`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

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 21, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only cover readOnlyHint=false, openWorldHint=true, and destructiveHint=false, which are minimal. The description goes far beyond by explaining the deterministic, no-vision-model approach, the classification of line types, projection reading, dimension handling, the output format (script and ledger), the verification process (re-projection and fidelity verdicts), and failure modes (raster-only). It also clarifies that dimension values override measured lengths and how assumptions are logged. This adds substantial behavioral context that the annotations do not provide.

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

Conciseness5/5

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

The description is dense but every sentence serves a purpose: it front-loads the use case, then explains the deterministic process, the output, verification, and error handling. It avoids fluff and doesn't repeat schema details unnecessarily. It is structured logically from what it does to how it works to outputs and exceptions, making it easy to scan.

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 6 parameters and no required ones, the description covers the core workflow, output format, verification behavior, and failure modes. Its mentions of output schema (though not detailed here) and the existence of a ledger and fidelity verdicts give a complete picture of what the agent will receive. It also tells the agent how to handle open facts (resolve_assumptions, set_param), which is crucial for follow-up. Nothing essential appears missing for correct invocation and interpretation.

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 100%, and the schema descriptions already explain each parameter well (e.g., 'path' as path to the PDF, 'verify' as evaluate and compare). The description adds value by clarifying the use of 'out' (writes ledger beside it) and the interaction between 'path' and 'pdfBase64' (inline vs. on-machine). It also implies 'projection' as an override, which the schema already states. Since schema covers parameters thoroughly, a baseline of 3 would apply, but the description's extra context on 'out' and the hosted server use-case earns a 4.

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?

Clearly states it converts a 2D engineering drawing PDF into a CAD script, distinguishes from photo-based or raster tools by naming trace_from_image as the alternative. The verb 'convert' and the resource type (drawing PDF) are specific, and the description explicitly excludes scanned (raster-only) pages, which differentiates it from similar tools.

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?

Explicitly states when to use this tool: when the reference is a 2D engineering drawing PDF with orthographic views, not a photo. It also gives a clear exclusion: scanned pages should use trace_from_image, and mentions resolving assumptions with resolve_assumptions and set_param for follow-up. This leaves no ambiguity about context or alternatives.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.