Skip to main content
Glama
seraphinernst4

Keystone for Vectorworks

vw2d_check

Read-only

Checks exact 2D drawing geometry for overlaps, gaps, duplicates, open outlines, and class/attribute issues, returning a numbered report and check image.

Instructions

Check drawing quality on the exact geometry and return a report (and a check image with numbered issues).

Finds: overlaps and stacked fills, gaps and slivers between neighbours, points that miss each other or an edge by up to tolerance_mm, duplicates, double lines, open or self-intersecting outlines, duplicate/redundant vertices, slivers and tiny objects, objects without class, attributes not 'by class'. Overlaps/gaps are compared between objects on the same layer (compare="layer"), the same class ("class") or everything ("all"); ignore_classes (e.g. ["Ausstattung*", "Schraffur"]) leaves out classes that overlap on purpose. checks: subset of overlap, duplicate, near, gap, self_intersection, open, double_line, vertices, tiny, classes, attributes, approx. Each issue suggests a vw2d_fix action. bbox [x1, y1, x2, y2] checks only objects touching that area (fast on big drawings). Precision: 0.005 mm; distances are measured on true arcs.

Input Schema

NameRequiredDescriptionDefault
bboxNo
imageNo
layerNo
uuidsNo
checksNo
compareNolayer
selectionNo
class_nameNo
max_issuesNo
tolerance_mmNo
ignore_classesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.3

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description is consistent with that. It adds genuine context beyond the annotations: the report plus a check image with numbered issues, the suggested fix action per issue, 0.005 mm precision, distances measured on true arcs, and the performance characteristic of bbox scoping. It does not say where/how the check image is produced or persisted.

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?

Front-loaded with the outcome, then the detection list, then parameter guidance. Dense and nearly every clause earns its place for an 11-parameter tool, though the run-on 'Finds:' block and mixed issues/params material could be segmented more cleanly.

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

Completeness3/5

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

Given 11 parameters and no output schema, the description does well to state the return shape and the core comparison/tolerance behavior. But it omits how the scoping parameters (layer, uuids, selection, class_name, image, max_issues) interact with the check, which an agent needs to scope a run correctly.

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

Parameters3/5

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

Schema coverage is 0%, so the description carries the full burden and does explain the hard parameters well: compare enum semantics (layer/class/all), an example for ignore_classes, the checks enum values, bbox scoping behavior, and tolerance_mm as the miss distance. However, image, layer, uuids, selection, class_name and max_issues are never mentioned, so several parameters remain undocumented anywhere.

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?

Specific verb + resource ('Check drawing quality on the exact geometry') immediately followed by an enumerated list of what it detects, which makes it unmistakable against siblings like vw2d_fix or vw2d_structure. An agent can select this without opening the schema.

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 gives real routing guidance: compare modes for what to compare against, ignore_classes for intended overlaps, bbox for speed on large drawings, and 'each issue suggests a vw2d_fix action' pointing to the remediation sibling. It lacks an explicit 'use this instead of X when...' exclusion statement, so it stops short of a 5.

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