Skip to main content
Glama

Component Contract Check

component_contract_check
Read-only

Validate a component against its builder brief before saving, catching contract violations early to avoid costly merge failures. Returns pass/fail details without raising.

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

A5/5.0
Behavior5/5

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

Annotations already mark readOnlyHint true and openWorldHint false; the description adds that it 'Never raises on a failing check,' explains skipped semantics (unverified is neither passed nor failed), and specifies return-shape behavior including the absence of the performance key when no performance contract is declared. This goes well beyond annotation coverage.

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?

Long but dense: every section (purpose, parameters, checks, return contract) earns its place and the critical timing is front-loaded. Issue-number references add minor noise but do not undermine the overall efficiency.

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?

With no output schema, the description documents the exact return shape {handle, ok, checks, reasons, skipped, performance?}, the meaning of ok, and skipped's role. It covers all checks run, key parameter semantics, and edge cases (no performance contract, no verdict yet), making it complete for an agent to call 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%, and the description compensates fully: handle is defined as the component's shaped object, and brief's three gate-driving keys (envelope, interfaces, performance) are each structurally described with semantics like PUBLISHED, tolerance, declared, and prove. It also clarifies that other brief keys guide the build, not the gate.

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 'Builder-side contract gate for one component' and positions it as the local half of the gate merge_assembly re-runs at fan-in. It names the specific action (check contract), the resource (component vs builder brief), and the sibling/alternative merge_assembly, so an agent can distinguish it.

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?

Explicitly instructs when to call: after building a component with the full AnkusDrive tool surface and BEFORE saving, against a builder brief. It contrasts the cheap local check with the expensive build → merge → gate-fail → rebuild loop and references merge_assembly as the fan-in re-run, giving clear placement among siblings.

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