mcp-server-kicad

Overview Schema Source Related Servers Discussions Admin

Check every footprint already on the board

validate_board

Read-onlyIdempotent

Validate all footprint placements in a KiCad board file against keep-out zones and board edge to prevent design rule violations before manufacturing.

Instructions

Validate all footprint placements against keep-out zones and board edge.

Each footprint's origin is checked as check_placement checks it: keep-outs read
as KiCad reads them, footprint keep-outs in board coordinates and layer sets
such as *.Cu included, and a footprint never flagged by its own keep-outs, which
KiCad's DRC never tests it against (pcbnew/pcbexpr_functions.cpp:697 at 9.0.8).

Args:
    pcb_path: Path to .kicad_pcb file. Optional; omit to use the configured default.

Input Schema

Name	Required	Description	Default
`pcb_path`	No

Output Schema

Name	Required	Description	Default
`status`	Yes
`violations`	Yes
`total_footprints`	Yes
`board_edge_checked`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.9.1Jun 10, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely useful behavioral context beyond that: how keep-outs are interpreted (KiCad semantics, board coordinates, *.Cu layer sets) and the non-obvious rule that a footprint is never flagged by its own keep-outs, backed by a source citation. This is real disclosure the annotations do not provide.

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 in one sentence, followed by a focused semantics paragraph and an Args block. The code citation is dense but earns its place by justifying the self-keep-out rule. Slightly heavy for a one-parameter tool, but nothing is wasted.

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?

With an output schema present, return values need not be described. The description covers the one parameter and the validation semantics it needs. It is nearly complete for a read-only validation tool, with only the exact invocation alternative to check_placement left implicit.

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?

Schema coverage is 0%, so the description carries the burden. It documents the sole parameter's meaning, accepted file type (.kicad_pcb) and, importantly, that it is optional and defaults to a configured value — semantics the bare schema ('default: ""') does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb and resource: 'Validate all footprint placements against keep-out zones and board edge.' The word 'all' and 'board' distinguish it from the single-placement sibling check_placement, which it explicitly references. It could state the board-wide scope even more sharply, but an agent can tell the two apart.

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?

Usage is implied by 'all footprint placements' and the reference to check_placement, but there is no explicit when-to-use/when-not statement or a direct alternative routing. An agent must infer that this is the board-wide validation pass rather than a per-footprint check.

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

Deploy Server