kernelcad

Repair CAD Script

repair_script

Use this when evaluate_script reported an error and you want the fix applied rather than described. Takes the candidates why_did_this_fail derives for a diagnostic, applies them one at a time, re-evaluates after each, and keeps the first that clears the diagnostic without introducing new errors. Never edits outside the repair region (failing feature statement + its input statements + the param() lines it reads) — an out-of-region patch is refused with tool.repair.out-of-region. Returns the repaired source in new_code (the caller persists it), a unified diff, and before/after health maps. Pass { file? | code?, diagnostic?: ''|'first-error', strategy?: 'apply-first'|'try-all'|'dry-run', max_attempts?: number }.

Input Schema

TableJSON Schema

Name	Required	Description
`code`	No	Inline kernelCAD script source.
`file`	No	Path to a .kcad.ts script file.
`strategy`	No	'try-all' (default) walks candidates until one clears the diagnostic; 'apply-first' applies only the top candidate and reports what it did; 'dry-run' previews every candidate patch without evaluating.
`diagnostic`	No	Diagnostic id from why_did_this_fail's `targetDiagnosticId` / `candidates[].diagnosticId`, or 'first-error' (default) for the first error-severity diagnostic.
`max_attempts`	No	Upper bound on candidates attempted (default 3). Ignored by apply-first and dry-run.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Whether a candidate cleared the target diagnostic without new errors.
`diff`	No	Unified diff of the accepted patch (dry run: every candidate patch).
`after`	No	Post-repair { ok, featureHealth, diagnostics }.
`error`	No
`before`	No	Pre-repair { ok, featureHealth, diagnostics }.
`target`	No	The diagnostic this run targeted { id, code, featureId?, message }.
`applied`	No	Candidate id that was accepted.
`attempts`	Yes	Per-candidate outcome { candidateId, applied, ok?, clearedDiagnostic?, newErrorCodes?, accepted, diagnostic? }.
`new_code`	No	Repaired .kcad.ts source (present when a patch applied). Caller persists it.
`strategy`	Yes
`errorCode`	No
`candidates`	Yes
`diagnostics`	No	tool.repair.* diagnostics when repair could not complete.
`repairRegion`	No	The line ranges the repair was bound to.
`candidateReason`	No
`candidateStatus`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 21, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations by describing the apply-re-evaluate-keep-first loop, the bounded repair region, the refusal error for out-of-region patches, and the fact that the caller persists the returned source. This gives the agent a clear model of side effects and boundaries.

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?

Each sentence earns its place: trigger, workflow, boundary constraint, return payload, and call shape. The information is dense but well ordered, and the final 'Pass {...}' block gives an at-a-glance parameter summary.

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?

For a complex repair tool, the description covers the trigger, algorithm, success criterion, failure/refusal behavior, return values, persistence responsibility, and parameter options. Nothing essential for correct invocation is missing.

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

Parameters4/5

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

The schema already covers all parameters at 100%, so the baseline is 3. The description adds useful invocation shape via the 'file? | code?' alternation and ties diagnostic/strategy values to the repair workflow, which provides small but real semantic value beyond the schema.

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 names a specific verb (repair), resource (CAD script), and trigger (evaluate_script reported an error). It also distinguishes itself from diagnosis-focused tools by stating it applies fixes rather than describing them, and explicitly ties into why_did_this_fail candidates.

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?

States exactly when to use it: after evaluate_script reports an error and when the fix should be applied rather than described. It also clarifies the alternative behavior (described fixes) and gives concrete invocation options, plus a hard constraint about the repair region.

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

All kernelcad tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.