kernelCAD

Run Electrical Rule Check

erc_run

Read-onlyIdempotent

Run an electrical rule check (ERC) on a schematic and return structured diagnostics — the KiCad ERC step, over MCP.

CHECKS: duplicate reference designators; net endpoints naming an unknown component or pin; unconnected pins (ignoring hidden power pins and explicit no-connects); single-pin nets; driver conflicts (two outputs on one net); power_in pins with no power_out source; input pins with no driver; no-connect markers on connected or non-existent pins; incomplete differential pairs; empty nets.

INPUT: schematic (same shape as netlist_export), ignore (optional array of rule codes to suppress, e.g. ["erc.net-single-pin"]), treatUnspecifiedAsPassive (optional; when true an "unspecified" pin counts as passive for the input-not-driven check).

OUTPUT: { ok, counts: { error, warn, info }, diagnostics: [{ code, severity, message, hint?, locus: { component?, pin?, net? }, nextAction? }], checked: { components, nets, pins } }. ok is true when there are zero errors. Diagnostics use the same shape as kernelCAD geometry diagnostics, sorted error → warn → info, deterministically.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "schematic": "<schematic>"
    },
    "name": "erc_run"
  }
}

Input Schema

Name	Required	Description
`ignore`	No	Rule codes to suppress, e.g. ["erc.net-single-pin"].
`schematic`	Yes
`treatUnspecifiedAsPassive`	No	When true, an "unspecified" pin counts as passive for the input-not-driven check.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavioral detail on top: deterministic error→warn→info sort order, the `ok` semantics (true only when zero errors), and what the diagnostics look like. It stops short of describing performance or size limits, but the added context is substantive.

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?

Purpose is front-loaded and the CHECKS list is dense but useful for tool selection. The OUTPUT block duplicates the existing output schema, which is mild redundancy, but the prose is otherwise tight with no wasted framing.

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

Completeness4/5

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

For a nested-schema, read-only analysis tool with an output schema and full annotations, the description covers what is checked, the inputs, and the result semantics well enough to invoke correctly. What remains thin is guidance on acting on the diagnostics (e.g., linking to why_did_this_fail or repair tooling).

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?

The INPUT block largely restates the schema, which already documents all three parameters at 67% coverage. The one genuine addition is the cross-reference that `schematic` has the same shape as netlist_export, which helps an agent construct valid input; the rest is duplication.

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 opens with a specific verb and resource ("Run an electrical rule check (ERC) on a schematic") and immediately grounds it as "the KiCad ERC step, over MCP". The CHECKS enumeration makes the tool's scope concrete and distinguishable from neighbors like netlist_export, verify, or dfm_review.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

It clarifies that the input has the same shape as netlist_export and that `ignore` suppresses rule codes, which implies the normal check-then-fix workflow, but it never states when to prefer this over siblings such as verify, review_cad, or lookup_diagnostics, nor lists any prerequisites or exclusions.

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

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.