Skip to main content
Glama
gchen19

AnkusDrive

by gchen19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

component_contract_check

Validate a built component against its builder brief before saving or merging. Catch envelope, interface, and performance violations locally and return pass/fail checks without raising on failure.

Instructions

Builder-side contract gate for one component (issue #169) — the local half of the gate merge_assembly re-runs at fan-in. Any MCP host builds a component with the full AnkusDrive tool surface, then calls this on its part BEFORE saving, against its builder brief (a ankusdrive.builder_brief/1 slice), and repairs any failing check. Catching a violation here turns the expensive loop (build → merge → gate-fail → rebuild) into a cheap local one. Never raises on a failing check.

handle: the component's shaped object. brief: a builder brief. Only three of its keys drive checks (the rest guide the build, not the gate): envelope {min:[x,y,z], max:[x,y,z]} the part's LOCAL bbox must fit inside. interfaces {name: {origin?:[x,y,z], z_axis?:[x,y,z], tol_mm?, angle_tol_deg?}} each named frame must be PUBLISHED (publish_interface) with a sane frame, and within tolerance of a pinned origin/axis if the brief gives one. performance {requirements?: [{name, limit}], required?: bool} the quantitative spec (#226) the builder must DECLARE (declare_performance, no looser than briefed) and PROVE (verify_performance) before fan-in.

Checks run: watertight (check_shape's one-clean-solid verdict), envelope (local bbox inside the keep-out box), interface: (published + sane + in tol), performance_spec: (declared as briefed) and performance: (the last RECORDED verify_performance verdict says it is met).

A performance requirement the record says is NOT met fails the gate. One with no verdict yet — never verified, a solve still in flight, or a verdict invalidated by a later edit — is neither passed nor failed: it comes back in skipped with a reason, because "unverified" is not "fine" and must not be actioned as either.

Returns {handle, ok, checks:[{check, passed, detail}], reasons:[...], skipped:[{check, reason}], performance?} — ok True iff every check passed (skips never move it); reasons is the failing checks' details. A part that declares no performance contract gets no performance rows, empty skipped and no performance key, so the geometric gate is unchanged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
briefYes
handleYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so richly: never raises on a failing check, ok is True iff every check passed, skips never move it, and unverified performance requirements return in `skipped` rather than passing or failing. It also enumerates the exact checks run and the meaning of ok/reasons/skipped/performance.

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 purpose and workflow position, then structured into labeled blocks for handle, brief keys, checks run, and return shape. It is long, but for a tool with nested objects and 0% schema coverage most of the text earns its place; a little prose repetition keeps it from a 5.

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?

Complete for this complexity: it explains the checks, the skip-vs-fail semantics, the return object, and the edge case where a part with no performance contract gets no performance rows and an unchanged geometric gate. Nothing an agent needs to invoke it correctly 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 must compensate and does: handle is 'the component's shaped object', and brief is a builder_brief/1 slice with its three gate-relevant keys (envelope, interfaces, performance) each explained with field shapes and semantics.

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?

States a specific verb+resource: a builder-side contract gate for one component, and explicitly positions itself as the local half of the gate that merge_assembly re-runs at fan-in. An agent can distinguish it from merge_assembly, envelope_check, verify_contract, and interface_align_check 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.

Usage Guidelines4/5

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

Gives clear when-to-use context: call it after building a component but BEFORE saving, against the builder brief, and repair failing checks, to convert an expensive build→merge→gate-fail loop into a cheap local one. It stops short of naming explicit alternatives or when-not conditions, but the workflow placement is unambiguous.

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