boardrepo

Read a board's PCB copper

read_pcb

Read-only

Use when the user asks how a public board is routed on copper: vias, pads, tracks, layers, or a PCB net's geometry. Returns the board's latest pcb graph (viewBox millimetres). No focus returns a bounded overview (board size, layers, via/pad/track counts, a net index with via counts and routed length). net returns that net's pads and vias (diameter, drill, layer span) plus track count and length — not a dump of every segment. ref returns one footprint's pads. pcb selects one PCB inside a multi-board project ("default" or a slug from the overview). Prefer this over reading raw .kicad_pcb text for vias and copper connectivity; read_schematic is schematic wiring, not copper. Copper pours (zones) are not in this graph; query_design select ["kicad_pcb","zone"] for those. If copper is still computing, say so rather than inferring vias from the schematic.

Input Schema

TableJSON Schema

Name	Required	Description
`net`	No	Optional. One copper net name (e.g. GND): returns its pads and vias (including drill and layer span) plus track count and routed length. Prefer this for 'how many vias on net X' or 'is this net's routing reasonable'.
`pcb`	No	Optional. One PCB inside this project: "default" or a slug from a previous overview (e.g. plate). This is NOT a BoardRepo board selector. Omit when the project has a single PCB.
`ref`	No	Optional. One footprint reference (e.g. U1): returns its pads with nets, layers and positions. Provide at most one of ref or net.
`board`	Yes	A board: handle/slug or a boardrepo.com URL. Use search_boards for public boards or list_my_boards for personal and authorised organisation boards. Do not invent references.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`pcb`	No
`url`	No
`hint`	No
`note`	No
`found`	Yes
`message`	No
`matchStatus`	No
`copperStatus`	No
`requestedNet`	No
`requestedPcb`	No
`requestedRef`	No
`copperAvailable`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 16, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds rich behavioral context: return variations by focus (overview, net, ref), pcb selection for multi-board, exclusion of zones, and instruction to say when copper is still computing rather than inferring. No contradiction.

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?

The description is dense but every sentence earns its place. It front-loads the primary use case, then explains return variations and limitations without fluff. Structure is logical and scannable.

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?

Given the tool's complexity (4 params, output schema, sibling tools), the description covers all necessary context: return types for each focus, pcb selection, zone exclusion, and behavioral caveat about copper computation. Nothing an agent needs to call it correctly is missing.

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?

Schema description coverage is 100% and each parameter is well-documented with examples and conditions (e.g., net returns pads/vias/drill/layer span). The tool description largely repeats the schema's parameter details, adding only minor clarifications like 'not a dump of every segment'. Baseline 3 is appropriate since schema does the heavy lifting.

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 clearly states the tool reads PCB copper routing (vias, pads, tracks, layers, net geometry) and distinguishes it from read_schematic (schematic wiring) and query_design (zones). The verb 'read' plus resource 'PCB copper' is specific and unambiguous.

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?

Explicit guidance is given: 'Prefer this over reading raw .kicad_pcb text for vias and copper connectivity' and 'read_schematic is schematic wiring, not copper.' Also tells when to use query_design for zones. This fully covers when to use this tool versus alternatives.

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

All boardrepo 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.