kschlint
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KICAD_CLI | No | Path to the kicad-cli executable. If not set, kicad-cli is expected on PATH. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| sch_lintA | Find layout problems in a KiCad schematic: overlapping texts, text on symbols or wires, wires through bodies, floating labels, wire ends on pin lines, missing junctions, dangling wires, off-grid points, title block overlap. Run after every schematic edit. Coordinates are mm, y down. |
| sch_renderA | Render one page to PNG (KiCad's own plot) and return it as an image, with findings boxed and numbered like sch_lint. Use region or around to zoom so text stays readable. tiles=true splits a full sheet into readable tiles. |
| sch_fixA | Move symbol fields (reference, value) and local labels out of collisions. Never touches symbols, pins, wires or connectivity. Dry run by default. With write=true it edits the files, checks the kicad-cli netlist is unchanged and restores the files if not. KiCad must be closed. |
| sch_inspectA | Exact geometry of symbols on a page: pin tip coordinates (where wires must end), pin direction, body box, field boxes. Without refs it also lists labels and wires. Use before drawing wires so they land on pin tips. |
| sch_free_spaceA | Find free, grid-aligned rectangles of w x h mm on a page, nearest to a point. Use to place a new block without collisions. |
| pcb_lintA | KiCad DRC of a .kicad_pcb. Silkscreen findings by default (reference on pads, on other silkscreen), all=true for everything. |
| pcb_renderA | PNG of a board region (F.Cu, silkscreen, courtyards, edge) as an image, silkscreen findings boxed. Use around (references) or region [x0,y0,x1,y1] mm. |
| pcb_fixA | Move reference designators flagged by DRC (and ones past the board edge) to the nearest clean spot next to their own part. Never moves footprints. With write=true it edits the board, re-runs DRC and restores the file if any non-silkscreen result changes. KiCad must be closed. |
| sch_checksA | List lint check codes with severity and meaning. |
| sch_selftestA | Compare the text geometry model with kicad-cli PDF output for a project. Run once after a KiCad update. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool targets a distinct operation: linting, inspecting geometry, rendering images, fixing collisions, finding free space, and listing check codes. The schematic and PCB groups are clearly separated by prefix, and even similar tools like sch_lint and sch_checks are unambiguous (one runs checks, the other lists them). No two tools appear to overlap in purpose.
The pattern is mostly consistent: domain prefix (sch_ or pcb_) followed by a noun or verb (lint, inspect, render, fix, free_space, checks, selftest). However, sch_free_space, sch_checks, and sch_selftest break the verb_noun convention, using noun phrases instead of actions like 'find_free_space' or 'list_checks'. Still, the prefix and readable names make it predictable.
With 10 tools, the server is well-scoped for its purpose of KiCad schematic and PCB linting, rendering, and fixing. Each tool covers a distinct need without redundancy, and the count is within the ideal range for a focused toolset. It feels neither thin nor bloated.
The schematic side has strong coverage: lint, inspect, render, fix, free space, checks, and selftest. The PCB side covers lint, render, and fix, but lacks a direct PCB geometry inspection tool (e.g., pcb_inspect) which agents might need for precise placement. Overall, the core workflows (detect, visualize, fix) are well-supported, with only minor gaps.