One line summary: Nestbolt's MCP server lets an AI agent import cutting artwork, nest parts onto fixed sheets, verify the result, estimate material needs, and export cut-ready files.
import_parts — Convert SVG/DXF outlines or a LightBurn .lbrn2/.lbrn project into a part library in millimetres; choose layers/colours, set curve tolerance, DXF/SVG unit overrides, optional gap closing; returns part ids, areas, bounds, layer kerf and warnings.
nest — Place library parts on fixed sheets with a repeatable budget (1–300 s) and seed; writes job.json, layout.json, report.json plus one SVG/DXF (or preserving LBRN2) per sheet; streams progress and returns independently checked metrics.
validate_layout — Run the independent Clipper2 validator on a layout against a request's parts, sheets and spacing; reports validity, violations and material metrics.
export_layout — Re-export a valid layout per sheet as SVG/DXF or preserving LBRN2, transforming original curves rather than re-polygonising; refuses invalid layouts.
estimate_sheets — Fast lower bound on sheet count (net part area ÷ usable sheet area) for planning/quotes, and flags parts that fit no sheet in any allowed rotation.
Request model — Parts with quantities, priority, mirroring and rotations (free, stepped, or a list like 0/180); sheets with margins, defect zones, remnant outlines, imported stock outlines and per-size counts; spacing, edge spacing, modes, and optional common-line kerf.
In the frozen v1 benchmark, 8.5% less material at the median than the best of Deepnest, SVGnest and Sparrow at equal 60-second budgets, and 9.6% at 300 seconds, in the final benchmark run (fresh seeds, ten held-out jobs). Sparrow still wins 8 of the 56 jobs at 60 seconds (details, every number).
Free, open-source nesting for people who cut fixed sheets: laser cutters, CNC routers, plasma, waterjet, fabric and leather. Nestbolt arranges parts so they use the least material. It runs in your browser (nothing is uploaded), on the command line, and as an MCP server that AI agents can call.
Open the browser app · Download a release · Connect an AI agent
The current development build supports editable LightBurn project nesting, lead-in
allowances and improvements for large curved drawings. The v1.1 plan is still
in progress; current verification and remaining work distinguish
completed features from open checks. Downloaded releases contain the features
listed in their own release notes. The hosted browser was last deployed from
v0.1.0; to try the
newer browser features, build the development app locally.
The benchmark figures below belong to the frozen 75cbb32 build, not a new
comparison of the development build.
451 parts on one 850 × 425 mm sheet in 120 seconds on one CPU core: DejaVu Sans
Bold glyphs in four sizes with their exact Bézier outlines, 90° rotations and
1 mm spacing. 29 letters sit inside the holes of others, and the unused material
stays as one clean offcut along the top. The layout passed the independent
validator. Rebuild it with python scripts/make_showcase.py --nest 120.
Final acceptance run (2026-10-13): 75 frozen sheet jobs (35 academic, 40 maker, ten of them held out from all tuning), equal time budgets, one CPU core per tool, five fresh seeds each, every layout checked by an independent validator. The comparison is against the best of Deepnest, SVGnest and Sparrow on each job, each with the better of its two settings.
Budget | Valid Nestbolt layouts | Less material than the best competitor (median) | Wins or ties |
60 s | 375/375 | 8.5% | 48 of 56 |
300 s (long subset) | 60/60 | 9.6% | 11 of 11 |
At 60 s Nestbolt uses less material than Deepnest on all 55 jobs where Deepnest produced a layout (median 9.9%) and than SVGnest on all 36 (14.4%). Sparrow, which Nestbolt builds on, wins 8 jobs. Seven are one-sheet jobs that Nestbolt hands to Sparrow itself after its own first layout, so Sparrow runs with slightly less time there; it is 0.03-2.4% better on them. The eighth (two sheets) is 0.34% better. That misses the project's own 60-second bar (wins or ties on 90% of jobs and never more than 1% worse); the 300-second, strip-parity and speed bars are met (status).
One benchmark job exactly as nested in a 60-second development run (m-mechanical-frame-inserts,
seed 0, sheet turned to landscape): 138 parts, all 39 inserts placed inside frame
windows, everything packed into 56% of a 2440 × 1220 mm sheet so the rest stays one
offcut. The best competitor used 62% of the sheet on this job.
In 30 s Nestbolt matches the competitors' 300 s result on 10 of 11 jobs. The first
final run (build 484ce8b) stopped with an error on one job; the fix is in 75cbb32
and both runs are published. Every run, including failures, is in
BENCHMARKS.md; status lists the evidence per
gate. The results page shows every
per-job number, tool revision, seed and the hardware; python scripts/reproduce.py --phase final --final-acceptance rebuilds the datasets, reruns what is missing and regenerates it.
Related MCP server: pyFit
Import SVG and DXF: lines, arcs, ellipses, Béziers, B-splines, blocks, transforms and units, converted to millimetres. Each closed outline is a part; outlines inside it are its holes. Choose cutting layers, identify stock outlines, and review repairs and unsupported geometry. See import options and the shop-file verification.
LightBurn projects (.lbrn2 and legacy .lbrn): nest groups as rigid units
and export an editable .lbrn2 per sheet, preserving original artwork, text,
images and layer settings. Tool and output-disabled shapes stay fixed. Older
text may need a separate native save to embed its outlines; mixed active/fixed
groups need regrouping before nesting. Import messages explain cached text,
bounding rectangles and missing curve controls. See LightBurn preparation.
Nest on fixed sheets: margins, part and edge spacing, several sheets, several stock sizes with limits, defects, remnant outlines, rotations (free, stepped or a list such as 0/180 for fabric grain) and mirroring. Small parts can sit inside the holes of larger parts. The last sheet is compressed towards one end so the offcut stays usable.
Export one SVG and one DXF per sheet from the original curves, transformed
rather than re-polygonised. LightBurn projects use preserving .lbrn2 output.
Export fidelity checks record the tested files and tolerances.
Lead-in allowances reserve room for leads and set contour starts, with shortened leads and unresolved contours reported explicitly. Red LEADIN paths are review guides; the cutting program creates the actual leads. Imported LightBurn projects keep their editable contents and receive separate SVG/DXF cutting files. See lead settings and CAM setup.
Common-line cutting, optional and still under development: identify shared straight cuts with kerf compensation. It can reduce cutting distance while increasing material use; two development jobs exceed the planned material limit. The export needs CAM preparation to avoid cutting shared sections twice. See common-line setup and limitations.
Check every result with an independent Clipper2 validator (overlap, spacing, containment, rotations, quantities). Invalid layouts are never returned.
Browser app (web/): the same engine compiled to WebAssembly in Web
Workers, automatic worker selection, a live view of the best layout, projects
saved in the browser or as a ZIP, and five one-click examples. Files never leave
the computer. An optional Quick initial layout setting helps start large
jobs. Current browser checks and native comparisons are tracked in
Status.
MCP server with import_parts, nest, validate_layout, export_layout
and estimate_sheets, tested with Claude Code. Its budgets are repeatable:
same build, inputs, work budget and seed give the same layout unless the real-time
limit is reached, which is reported explicitly. See
the agent interface.
The engine builds on jagua-rs and sparrow by Jeroen Gardeyn and collaborators (arXiv 2509.13329). Fixed-sheet search lays the last sheets end to end as one walled strip and shrinks the last sheet with a port of Sparrow's separator; parts move between sheets and an emptied sheet disappears. Near-rectangular parts such as box panels also get a bounding- rectangle packing start. One sheet of hole-free parts without defects is exactly Sparrow's own strip-packing problem, where it is the state of the art, so there Nestbolt runs unmodified Sparrow for the rest of the budget.
Use the browser app without installing
anything, or download native tools for Windows x64, Linux x64 or macOS Apple
silicon from Releases. Each
archive contains nestbolt, nestbolt-mcp and licences; download checksums are
provided alongside it. The separate Windows MCPB bundle installs the server in
Claude Desktop; see
agent setup.
To build the development version, install Rust through rustup (the repository selects Rust 1.98.1):
cargo build --release -p nestbolt-cli -p nestbolt-mcpImport parts, nest them for 30 seconds, and get per-sheet SVG/DXF files
(examples/box-99x63x45.svg is the browser app's example box):
target/release/nestbolt import examples/parts.svg --output library.json
target/release/nestbolt nest --library library.json --request examples/nest-request.json --out-dir run --seconds 30For drawings with larger gaps, import --close-gaps 0.05 explicitly repairs up
to 0.05 mm and reports every repair's position and size. It is off by default;
the silent join limit remains 0.005 mm. The UI and MCP expose the same option.
See import options and reports.
Lead reservations and contour starts are available in the browser, request JSON
and nest --lead-in --kerf ...; see settings and LightBurn setup.
A request names library parts with quantities and the sheets in millimetres:
{
"parts": [{"id": "parts-1", "quantity": 4}, {"id": "parts-2", "quantity": 12, "rotations": {"kind": "free"}}],
"sheets": [{"width_mm": 600, "height_mm": 400, "margins_mm": {"left": 5, "right": 5, "bottom": 5, "top": 5}}],
"spacing_mm": 1.0,
"edge_spacing_mm": 1.0
}run/ then holds layout.json, report.json and sheet-0.svg/sheet-0.dxf and
so on. Existing files are never overwritten. nestbolt export re-exports a
layout; nestbolt validate checks a polygon job and layout. Add --repeatable
to nestbolt nest or nestbolt sheets for a deterministic work budget instead of
wall-clock time: the same inputs, budget and seed then give the same layout. On a
machine much slower than the reference PC, --time-limit <seconds> allows more real
time for the same work (the default is --seconds).
The optional --quick-start setting tries a conservative initial arrangement
before improving it. It is off by default and may use more material. The browser
calls it Quick initial layout under Advanced; request JSON and MCP use
"quick_start": true. Original geometry, spacing, stock limits and rotation
permissions still apply. Unsupported stock or angle rules use the ordinary
constructor.
File formats are described by the JSON Schemas.
Open it and pick an example (finger-jointed boxes, letters inside letters, a 138-part mechanical kit, a FreeSewing T-shirt pattern on a fabric roll, interlocking gears), or drop your own SVG/DXF files or one LightBurn project. The best layout so far is drawn while the search runs, and each sheet shows the box around its parts and the clear offcut left above them.
To build it locally you need the wasm32-unknown-unknown target, wasm-bindgen-cli
0.2.129 and Node.js 24; then open the printed address:
cd web && npm ci && cd ..
python scripts/build_web.py
npm --prefix web run previewpython scripts/build_web.py --test also runs the Playwright tests in Chromium
and Firefox.
Register the MCP server with an absolute path, for example in Claude Code:
claude mcp add --transport stdio --scope local nestbolt -- /path/to/target/release/nestbolt-mcpThe server reads and writes only inside its working directory (or
NESTBOLT_WORKSPACE). docs/AGENT_INTERFACE.md covers
Claude Code, Codex and Claude Desktop, the request format and the rules.
python scripts/check.py
python scripts/sheets_batch.py --cpu 0 --cpu 2 --seconds 60The first runs format, lint, all Rust and Python tests, WebAssembly builds,
notice and dataset checks; add --web for the browser build and tests. The second runs the development benchmark (held-out
jobs excluded) and writes an audited report under benchmarks/results/.
Path | Purpose |
| Geometry import/export, sheet search, separator, part-in-part |
| Command-line interface |
| Native stdio MCP server |
| Independent Clipper2 checker and material scoring |
| WebAssembly boundary for the browser app |
| Browser app (Preact, Vite) and its Playwright tests |
| Frozen datasets, competitor runners and all results |
| Original v1 plan and acceptance gates |
| Current shop-file and cutting-feature plan |
| Milestone evidence and next steps |
Every benchmark run, including failures, is logged in BENCHMARKS.md.
Progress counts finished milestones only; see docs/STATUS.md.
Nestbolt is MIT. jagua-rs is an unmodified MPL-2.0 dependency; the
separator in crates/core/src/separate.rs is adapted from Sparrow (MIT).
THIRD_PARTY_NOTICES records every dependency and licence.
A fast lower bound on sheets for planning and quotes: net part area divided by usable sheet area. Necessary, not sufficient: real layouts can need more sheets. Also flags parts that fit no sheet in any allowed rotation.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | ||
| library_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the approximation semantics (fast lower bound, guaranteed not to overstate), the failure-flagging behavior for unplaceable parts, and that rotation constraints are considered. It says nothing about error cases or the exact output shape, but the core behavioral contract is honest and explicit.
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?
Two sentences, front-loaded with the core computation and followed by the caveat and the side-effect flag. No filler and every clause carries information.
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 two-parameter analytic tool with no output schema and no annotations, the description supplies the computation model, the interpretation of the result (lower bound), and the extra output signal (unplaceable parts). Only the required library_path input and any error/validation conditions are left unaddressed.
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% at the top level, so the description must compensate for library_path and request. It conveys the domain model (net part area vs. usable sheet area, allowed rotations) that implicitly frames parts/sheets/spacing, but never mentions library_path or the request envelope, leaving the two required inputs undocumented in prose.
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 a specific verb+resource (estimate sheets) and even the method: net part area divided by usable sheet area. It distinguishes itself conceptually from a true nesting tool by calling itself a lower bound, though it never names the sibling 'nest' explicitly.
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?
"For planning and quotes" gives a clear when-to-use context, and "necessary, not sufficient: real layouts can need more sheets" implicitly warns against using it in place of a real layout run. It stops short of explicitly routing the agent to the sibling tool for actual layouts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write per-sheet SVG/DXF or preserving LBRN2 for a valid layout, transforming the original curves (arcs and splines stay curves). Refuses invalid layouts.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Optional svg, dxf or lbrn2; omit to use the source format default. | |
| out_dir | Yes | New output directory; preserving .lbrn2 for LightBurn, SVG/DXF otherwise. | |
| request | Yes | ||
| layout_path | Yes | ||
| library_path | Yes | ||
| sheet_outline | No | Draw sheet boundaries (default true for LightBurn, false for SVG/DXF). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but does add real behavioral detail: it writes per-sheet files, preserves curve types (arcs/splines stay curves), and refuses invalid layouts as an error path. It omits whether it overwrites existing files, creates out_dir, permissions, or what it returns.
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?
Two sentences, verb front-loaded, no filler. The only weakness is the awkward 'or preserving LBRN2' clause that momentarily obscures the format options.
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?
A complex, deeply nested request schema with no output schema and no annotations, yet the description never explains return values (file paths? manifest?) or the failure mode beyond 'refuses invalid layouts'. Given the missing structured fields, it does not do enough.
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?
At 50% schema description coverage, layout_path and library_path are undocumented and the description compensates for none of it. It only loosely maps to the format option (svg/dxf/lbrn2) without clarifying out_dir, request, or sheet_outline 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 names a specific verb ('Write') and resource (per-sheet SVG/DXF or LBRN2 files for a layout), so the export intent is clear. However, the phrasing 'or preserving LBRN2' is grammatically muddled and it never contrasts itself with siblings like validate_layout or nest.
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?
There is no explicit statement of when to call this versus alternatives such as validate_layout. The clause 'for a valid layout' implies a precondition (the layout must already be valid) but never tells the agent to validate first or what to do otherwise.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import SVG/DXF outlines or one LightBurn lbrn2/lbrn project into a part library (mm). LightBurn groups stay rigid and original artwork/settings are retained for lbrn2 export. Writes the library to a file and returns part ids, areas, bounds, layer kerf and import warnings. Use the ids in nest requests.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | SVG/DXF files or one .lbrn/.lbrn2 project, inside the workspace. | |
| colors | No | DXF ACI numbers as strings (e.g. "7") or RGB colours (e.g. "#000000"). | |
| layers | No | Cut layer names; omit to prefer cut/outline/profile, then all closed contours. | |
| dxf_unit_mm | No | Millimetres per DXF unit when `$INSUNITS` is missing (default 1). | |
| library_path | No | Where to write the part library JSON; a new file under `nestbolt/` by default. | |
| sheet_layers | No | Stock-outline layers offered separately from parts (defaults to SHEET). | |
| tolerance_mm | No | Maximum distance between exact curves and nesting polygons, in mm (default 0.005). | |
| close_gaps_mm | No | Explicitly close gaps up to this many mm (off by default, maximum 1). | |
| svg_user_unit_mm | No | Millimetres per SVG user unit when a document has no absolute size (default 25.4/96). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does well: it discloses that a file is written, the default write location, that units are mm, that LightBurn groups stay rigid, and that original artwork/settings are retained for lbrn2 export. It stops short of stating overwrite behavior or permission/workspace constraints on a mutating tool.
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?
Four dense sentences with zero filler, front-loaded with the core action and ending with the actionable handoff to nest. Slightly dense with behavioral detail packed in, but nothing is wasted.
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?
No output schema exists, so the description's enumeration of return values (part ids, areas, bounds, layer kerf, import warnings) is essential and present. For a 9-parameter mutating tool with no annotations, the main remaining gap is write/permission semantics rather than return behavior.
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 100%, so all nine parameters are already documented in the schema. The description adds only the '(mm)' unit note and the 'one LightBurn project' constraint, which the schema largely covers; baseline 3 applies when the schema does the heavy lifting.
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?
States a specific verb (import) and resource (SVG/DXF outlines or a LightBurn lbrn2 project) into a named target (part library, in mm). The scope is precise enough that an agent can tell it apart from nest/export_layout/validate_layout without opening any schema.
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?
Gives a clear workflow context: this is the upfront import step and 'Use the ids in nest requests' names the downstream tool. However, it never states when NOT to use it or how it relates to the other siblings (estimate_sheets, validate_layout, export_layout), so the routing guidance is one-directional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nest library parts on fixed sheets with a repeatable budget (time_budget_s, at most 300). Writes job.json, layout.json, report.json and one SVG and DXF per sheet (preserving LBRN2 for LightBurn); returns the independently checked metrics. Sends progress notifications.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Random seed (default 0). The same inputs, budget and seed repeat exactly. | |
| out_dir | No | New output directory; `nestbolt/runs/<name>` by default. | |
| request | Yes | Parts (ids from `import_parts`, quantities, rotations), sheets and spacing, in mm. | |
| library_path | Yes | A library written by `import_parts`. | |
| time_budget_s | No | Search budget in seconds, 1 to 300 (default 10). Also the hard real-time limit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses the written artifacts (job.json, layout.json, report.json, SVG/DXF per sheet, LBRN2 preservation), the repeatability guarantee tied to budget/seed, and outbound progress notifications. It does not mention permissions, what happens if out_dir already exists, or failure 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?
Two dense sentences, front-loaded with the primary action and budget constraint, followed by side effects and return value. No filler clauses.
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?
No output schema exists, so the description must cover returns, and it does indicate that independently checked metrics are returned alongside the artifact paths. 'Metrics' remains undefined in structure, but combined with the rich 100%-covered input schema it is complete enough to call 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?
Schema description coverage is 100%, so the schema already documents all five parameters. The description only restates the time_budget_s cap (300) and adds no syntax or format meaning beyond the schema, so the baseline 3 applies.
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?
Specific verb ('nest') plus resource ('library parts on fixed sheets') with scope details (budget, artifacts). It is clearly distinguishable from estimate_sheets and export_layout without opening the schema, though it never names or contrasts a sibling explicitly.
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 only implied: the tool is evidently the actual nesting run, whereas estimate_sheets, export_layout and validate_layout are adjacent. No statement of when to choose this over alternatives, no prerequisites (e.g. that library_path must come from import_parts) beyond a passing schema note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a layout file against the library parts, sheets and spacing of a request with the independent validator; returns validity, violations and material metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | ||
| layout_path | Yes | A layout JSON file, for example `layout.json` written by `nest`. | |
| library_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does disclose the return shape (validity, violations, material metrics) and the fact that validation is independent, but omits whether it is read-only, whether it fails or returns a report on invalid layouts, and any performance/IO characteristics.
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?
A single sentence, front-loaded with the action and the objects it operates on. Every clause earns its place, and the return values are tacked on efficiently.
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?
No output schema and no annotations, so the description must do more. It names the return fields but leaves out prerequisites, error behavior, and path semantics, leaving an agent with only a viable minimum for a 3-param tool.
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%, and the description only loosely implies the three required params (layout file, library, request). It adds no syntax, format, or path semantics beyond what the schema partially provides, so it does not compensate for the coverage gap.
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 opens with a specific verb and resource ('Check a layout file against the library parts, sheets and spacing of a request'), and names a distinguishing trait ('the independent validator') that separates it from nesting siblings like nest or estimate_sheets.
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 'against ... a request' and 'independent validator', suggesting post-nest verification, but the description never says when to call it versus siblings like estimate_sheets or export_layout, nor any preconditions. No explicit exclusions.
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.0estimate_sheetsexport_layoutimport_partsnestvalidate_layoutScored across 5 tools
Each tool maps to a distinct pipeline stage: import, estimate, nest, validate, export. There is minor overlap between nest and export_layout (both produce SVG/DXF), and estimate_sheets versus nest could be confused, but the descriptions clearly distinguish planning/estimating from actual nesting.
Four tools follow a consistent verb_noun snake_case pattern (estimate_sheets, export_layout, import_parts, validate_layout). 'nest' is a bare verb without a noun, which is a minor deviation but still readable and predictable.
Five tools are well-scoped for a nesting workflow; each covers a necessary stage (import, estimate, nest, validate, export) without redundancy or missing steps.
The surface covers the full lifecycle from importing parts through estimating, nesting, validating, and exporting layouts. Minor gaps exist around managing existing part libraries (no list/delete/update tools), but the core workflow is complete and agents can work around these limitations.
Headless CAD engine & MCP server for 2D/3D drafting, solids, DXF/SVG export, and automation.
Cutlist optimization for sheet, linear and roll stock, with grain, kerf, nesting and saw exports.
Pack cargo into containers & onto pallets; a verifiable 3D loading plan. Free tier + REST API.
Real 3D-print slicing, quoting, DFM, orientation & material/settings advisors. Free personal tier.
