Skip to main content
Glama
pzfreo

build123d-mcp

lint_drawing

Read-only

Check build123d drawings for structural violations including label-measured mismatches, overlaps, redundant lines, and page bounds. Use before rendering to catch bugs early.

Instructions

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
NameRequiredDescriptionDefault
svg_pathNo
drawing_scaleNo
view_shape_namesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Annotations declare readOnlyHint=true; the description confirms it runs checks and returns violations without side effects. It adds significant behavioral detail: two modes, specific checks performed, and how drawing_scale affects false positives. This adds value beyond the annotations.

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 somewhat long but well-structured with sections and bullet-like lists. Key information is front-loaded (purpose and return format). Each sentence adds value, though some details could be more concise. Overall effective.

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?

Given the tool has an output schema (violations) and three parameters, the description covers all important aspects: modes, parameter semantics, violation structure, and usage timing. It is self-contained and sufficient for an agent to understand and invoke the tool correctly.

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 coverage is 0%, so the description must explain all three parameters. It does so thoroughly: svg_path triggers SVG mode, drawing_scale adjusts label-vs-measured checks with default 1.0, view_shape_names detects view overlaps. Each parameter's purpose, usage, and defaults are clearly described.

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 clearly states the tool runs structural drawing-quality checks, returns JSON with violations, and lists specific categories (label divergence, overlaps, etc.). It distinguishes session mode (annotations) from SVG mode (SVG file scanning), making the purpose concrete and differentiating it from sibling tools like inspect_drawing.

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

Usage Guidelines4/5

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

The description advises 'Run this after major drawing additions; running it BEFORE rendering catches the bug at the source.' It also explains when to use each mode (session vs. SVG). However, it does not explicitly state when not to use the tool or name alternatives, though the context is clear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pzfreo/build123d-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server