build123d-mcp

Overview Schema Source Related Servers Discussions Admin

lint_drawing

Read-only

Runs structural quality checks on CAD drawings and returns JSON violations, detecting label mismatches, overlaps, and export issues before rendering.

Instructions

DEPRECATED (#465) — moved to draftwright; off by default in 0.4.0, removed in 0.5.0. Calling it explains the replacement. Run structural drawing-quality checks and return JSON {violations: [...]}.

Session mode (default): reconstructs the session's annotations and delegates
to build123d-drafting-helpers (lint_drawing + find_interferences) — single
source of truth. Surfaces label-vs-measured divergence (axis swap), Leader
line through its own label, annotation/label overlap, a witness/extension
line piercing a neighbour's label, redundant collinear lines, and page-bounds
overshoot.

SVG mode (svg_path set): scans an SVG file for export-only pathologies — most
importantly native <text> elements (build123d renders glyph paths, so any
<text> won't DXF-export and won't scale with the model).

drawing_scale: when the geometry was scaled up before projecting — e.g. a
7.5 mm feature drawn at 5:1 via part.scale(5) — pass the same factor (5.0)
so the label-vs-measured check divides each measured path length by it
before comparing to the label. This lets labels carry the *real* dimension
while the geometry is drawn enlarged, instead of every dim tripping a false
axis-swap warning. Session mode only; defaults to 1.0 (no scaling).

view_shape_names: list of shape names (from show()) representing the placed
view outlines. Used to detect view_annotation_overlap (annotation bbox
overlaps a view outline) and view_overlap (two view outlines overlap).
Pass the visible-side placed compounds from each projection, e.g.
["front_placed", "side_placed", "plan_placed", "iso"]. Session mode only.

Each violation is {severity, check, object, message}. Run this after major
drawing additions; running it BEFORE rendering catches the bug at the source.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`svg_path`	No
`drawing_scale`	No
`view_shape_names`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.3.42Jun 10, 2026

addedInput schema / properties / view_shape_names

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "View Shape Names"
+}

Changed1 schema field changedv0.3.33Jun 4, 2026
- addedInput schema / properties / drawing_scale
```
Added value: +{
+  "default": 1,
+  "title": "Drawing Scale",
+  "type": "number"
+}
```
Addedv0.3.27May 31, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true, and the description does not contradict this; it consistently describes read-only analysis. The description adds valuable context about internal delegation, the exact violation types checked, and the return format. It also discloses that calling the deprecated version 'explains the replacement,' a behavioral nuance beyond the annotation.

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 description is long but well-structured: deprecation notice, purpose, mode breakdown, parameter details, and a usage tip. It is front-loaded with the most critical info. A few sentences are dense, but each serves a purpose; minor redundancy exists in repeating mode conditions.

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 tool with two modes, three parameters, and a structured output, the description covers everything an agent needs: operation, parameter semantics, when to run, and deprecation status. The return format is specified as {violations: [...]}. No critical information is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden for parameters. It thoroughly explains svg_path (SVG mode), drawing_scale (with a concrete 5:1 example and division logic), and view_shape_names (with example list). Defaults are stated. This far exceeds the bare schema definitions.

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?

The description states a clear verb and resource: 'Run structural drawing-quality checks and return JSON {violations: [...]}.' It enumerates specific checks (axis swap, leader-through-label, etc.), which distinguishes it from sibling drawing tools like inspect_drawing or render_drawing. The deprecation notice further clarifies its current role.

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?

Explicit guidance is provided: 'Run this after major drawing additions; running it BEFORE rendering catches the bug at the source.' It also distinguishes session mode vs. SVG mode based on svg_path, and explains when drawing_scale and view_shape_names should be used. Alternatives are implied via the deprecation notice pointing to draftwright.

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