Skip to main content
Glama
gchen19

AnkusDrive

by gchen19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Drawing Gate

drawing_gate
Read-only

Validate drawing manufacturing completeness by checking dimension coverage against the solid; return a gate with violations for missing, redundant, conflicting, unanchored, or extra dimensions.

Instructions

Manufacturing-completeness gate for a drawing page: does the placed dimension set fully and non-redundantly reconstruct the part? A green render is not a manufacturable drawing — this validates the drawing itself, the way the geometry-realizes-declaration gate validates an assembly.

Reads the real solid + the placed dimensions and accounts degrees of freedom, process-aware: a 'prismatic' (milled/plate) part must locate each hole by X/Y from a datum and size the block W×H×T; a 'turned' part is concentric, so a step needs only Ø + axial length. process='auto' infers it from the geometry.

Returns {ok, violations, slots_total, slots_covered, process, features, dimensions, enumerated_features, datum_faces, section_recommended}. section_recommended ({recommended, reasons, feature_ids}) advises whether the part has internal geometry that needs a cross-section (see add_section_view). Each violation has a code (under = a feature size/location is missing; redundant = a DOF dimensioned more than once; conflict = dimensioned twice with disagreeing values; extra = a dim that pins nothing; no_datum = a location not taken from a datum) and a human reason. ok=True (empty violations) means the drawing is manufacturing-complete.

Datum-origin discipline turns on automatically when the part has faces annotated role='datum' (annotate_face): a location dimension not measured from a datum face is then flagged no_datum. Set datums_declared=True to force the check on even without annotated datums.

require_ballooned=True additionally demands that every characteristic carries an inspection balloon (see balloon_drawing) — the requirement a release flow imposes when the drawing must ship with an inspection plan. Unballooned characteristics become not_ballooned violations and fail the gate. The ballooned ({ok, total, ballooned, missing}) summary is reported either way.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageYes
processNoauto
datums_declaredNo
require_balloonedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, but the description goes far beyond this, detailing the return object, violation codes (under, redundant, conflict, extra, no_datum, not_ballooned), process-aware behavior, datum-origin discipline, and ballooning requirements. This is comprehensive behavioral disclosure that fully compensates for the minimal annotation.

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 long but meticulously organized: purpose first, then return-value explanation, violation codes, datum behavior, and ballooning. Every sentence adds substantive value, and the structure front-loads the core purpose before diving into details. No filler or repetition.

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?

Despite having no output schema, the description fully documents the return object and its fields, including section_recommended and ballooned summaries. It covers process-aware logic, datum handling, and ballooning, leaving no ambiguity about inputs, behaviors, or outputs. The complexity of the tool is matched by the completeness of its description.

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?

With 0% schema description coverage, the description carries the entire burden of explaining parameters. It explains 'process' (including 'auto' inference), 'datums_declared' (forces datum checking without annotated datums), and 'require_ballooned' (mandates inspection balloons). The required 'page' is self-explanatory, but all optional parameters are well-elaborated.

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's purpose: a manufacturing-completeness gate that validates whether the placed dimension set fully and non-redundantly reconstructs the part. It distinguishes itself from other gates (e.g., geometry-realizes-declaration) and from siblings like drawing_legibility, making the tool's role unambiguous.

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 provides strong contextual guidance: it explains when the gate applies (after a green render, to validate the drawing itself), and references related tools (annotate_face, add_section_view, balloon_drawing) that affect behavior. However, it does not explicitly state when to prefer this over alternatives like drawing_legibility, relying on context rather than explicit contrasts.

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

Deploy Server

Other Tools