boardrepo

Server Details

Search and review real KiCad and Altium PCB designs: schematics, BOMs, netlists, DRC/ERC.

Ownership verified

Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.

If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.

Status: Unhealthy
Uptime: 78.3% over 42 days
OAuth: Works in Glama
Last Tested: 2026-10-02 12:05
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: flintt-dev/boardrepo-plugin
GitHub Stars: 0

TDQS

A4.6/5.0

Scored 2026-09-26 05:46 across 12 tools

Disambiguation4/5

Each tool has a distinct purpose and the descriptions carefully police boundaries, especially among read_file, read_pcb, read_schematic, query_design, and search_board. The main risk is that several content-access tools exist in the same domain, so a less careful agent could pick the wrong reader, though the descriptions largely prevent this.

Naming Consistency5/5

All names follow a consistent lowercase snake_case verb_noun pattern: get_*, list_*, read_*, search_*, plus query_design and run_checks. The plural search_boards is also clearly differentiated from the singular search_board, and each verb accurately reflects the tool's action.

Tool Count5/5

Twelve tools is well within the ideal scope for this domain and each tool earns its place: metadata lookup, file listing, raw reads, two specialized readers, structure queries, BOM access, DRC/ERC checks, and fab profiles. There is no obvious redundancy or bloat.

Completeness4/5

The read/analyze lifecycle is well covered: search, board metadata, file access, schematic and PCB analysis, BOM, and both stored and runnable checks. The main gap is that get_board references list_my_boards, but no such tool is exposed, leaving a minor hole for private-board enumeration.

Available Tools

12 tools

get_boardGet a board overviewA

Read-onlyIdempotent

Inspect

Read a named board, boardrepo.com URL, or result from search_boards or list_my_boards. Non-public personal boards require read:own; organisation boards require read:org and current board permission. Returns metadata, a bounded README excerpt, tags, license, source EDA format, detected KiCad version, capabilities, file count and canonical URL. Do not invent references. For the design, use read_schematic (schematic wiring), read_pcb (copper: vias, pads, tracks), get_bom (parts), or list_board_files then read_file (source).

ParametersJSON Schema

Name	Required	Description	Default
`board`	Yes	A board: handle/slug or a boardrepo.com URL. Discover public boards with search_boards, personal or authorised organisation boards with list_my_boards.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's reading behavior is consistent. It adds valuable context beyond annotations: the bounded README excerpt, the list of returned metadata fields, the canonical URL, and a 'do not invent references' constraint. This goes beyond what annotations alone convey, earning a 4.

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?

Three sentences, each earning its place: the first states the input scope, the second summarizes outputs and permissions, and the third routes to siblings. No redundancy, no filler, and the most important scoping info is front-loaded.

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 single-parameter, output-schema-provided, read-only tool, this description is complete. It covers how to obtain valid inputs, what permissions are needed, what the returned data includes, and which sibling to pick for deeper design details. An agent can invoke this tool correctly without external information.

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 coverage is 100% — the `board` parameter is already fully documented as a handle/slug or boardrepo.com URL, with discovery guidance pointing to search_boards and list_my_boards. The description largely restates the accepted input forms and the permission caveat, adding no new syntax or detail beyond the schema, so it stays at the baseline 3.

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 'Read a named board...' giving a specific verb and resource, and enumerates accepted input forms (named board, boardrepo.com URL, or results from search_boards/list_my_boards). It also names sibling alternatives (read_schematic, read_pcb, get_bom, list_board_files) and what each is for, so an agent can clearly differentiate this overview tool from design-specific readers.

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 when-to-use and when-not-to-use guidance is embedded: 'For the design, use read_schematic... read_pcb... get_bom... or list_board_files then read_file.' It also states how to discover inputs via search_boards and list_my_boards, and notes permission prerequisites (read:own, read:org plus current board permission).

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

get_bomGet a board's BOMA

Read-onlyIdempotent

Inspect

Use when the user asks which parts a public board uses: reference designators, quantity, value, footprint, MPN, manufacturer, DNP, and datasheet. Returns up to 200 lines per call (pass the returned cursor for more). Pass include_pricing to also get live best unit price, in-stock quantity, and lifecycle-risk per part. No device pinouts. Search first if the board is unknown; use read_schematic for schematic wiring and read_pcb for copper vias/pads.

ParametersJSON Schema

Name	Required	Description
`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.
`cursor`	No	Opaque pagination cursor from a previous call; pass to fetch the next page.
`include_pricing`	No	When true, add live sourcing to each line: best unit price, currency, in-stock quantity, lifecycle-risk band, and whether the price is an estimate. Pass it whenever the user asks about cost, sourcing, availability, or 'how much'. Prices come from distributors and may be partial or absent for obscure parts; this makes the call slower than the static BOM, so leave it off for a plain parts list.

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`lines`	Yes
`total`	Yes
`nextCursor`	Yes
`hasNextPage`	Yes
`derivedFromPcb`	Yes
`pricingIncluded`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark readOnlyHint/idempotentHint/destructiveHint false, and the description adds pagination behavior (200 lines per call, pass cursor), slower response when include_pricing is enabled, and partial/missing pricing for obscure parts. These are useful behavioral disclosures that go beyond the annotations.

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 five compact sentences, front-loaded with the use case and output fields. Every sentence contributes: trigger, pagination, pricing mode, exclusions, and sibling routing, with no promotional or redundant filler.

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 read-only, 3-parameter tool with an output schema, the description covers trigger, board resolution, pagination, pricing-mode behavior/trade-offs, exclusions, and sibling routing. Nothing needed to invoke it correctly or avoid confusing it with related tools 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?

Schema coverage is 100% and each parameter is richly described, so the baseline is 3. The description adds the concrete pagination limit of 200 lines and reinforces that the cursor should come from a previous call, which is slightly more than the schema's generic 'pass to fetch the next page'.

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 concrete trigger—'user asks which parts a public board uses'—and enumerates the returned BOM fields (reference designators, quantity, value, footprint, MPN, manufacturer, DNP, datasheet). It also distinguishes the tool from siblings by declaring 'No device pinouts' and routing read_schematic/read_pcb usage to their own domains.

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?

It tells the agent exactly when to use get_bom, when to pass include_pricing (cost/sourcing/availability questions), and to search first if the board is unknown. It explicitly names read_schematic and read_pcb as the alternatives for schematic wiring and copper vias/pads, so there is no ambiguity about tool selection.

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

get_checksGet a board's DRC and ERC resultsA

Read-onlyIdempotent

Inspect

Use when the user asks whether a board passes KiCad's own checks, or before trusting a design: returns the stored DRC (design rules, unconnected copper, schematic-vs-board parity) and ERC (electrical rules) results for the board's current version, with exact error and warning counts per category and paged example violations. These are KiCad's checks as the board's author configured them, so rules they waived were never evaluated and are listed separately. This is not a design review. If the checks have not been run for this version the result says so, and that is NOT the same as passing.

ParametersJSON Schema

Name	Required	Description
`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.
`rules`	No	Optional: YOUR OWN limits in millimetres, when no published fab profile fits - an in-house process, a tier a vendor does not publish, or a house rule tighter than any of them. Keys are the same limit names list_fab_profiles reports (trackWidthOuterMm, clearanceOuterMm, drillPlatedMinMm, annularMinMm and so on); values are millimetres. Mutually exclusive with vendor. The result is never stored as if a fab had published it.
`cursor`	No	Opaque pagination cursor from a previous call; pass to fetch the next page of violations.
`vendor`	No	Optional fab house id from list_fab_profiles. Returns geometric checks against that fab's stored profile for this board instead of the board's own DRC/ERC. Do not invent an id.
`category`	No	Optional: return only this category's violation details. Counts for every category are always returned regardless.

Output Schema

ParametersJSON Schema

Name	Required	Description
`ran`	Yes
`note`	No
`vendor`	No
`errorCount`	No
`nextCursor`	No
`violations`	No
`hasNextPage`	No
`vendorLabel`	No
`warningCount`	No

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it explains that waived rules are listed separately, that unrun checks are reported as such and are NOT the same as passing, and that the result is the board author's configured checks. This is meaningful behavioral disclosure that helps an agent interpret results correctly.

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 compact and front-loaded: the first sentence states the primary use case and what the tool returns. Every subsequent sentence adds essential interpretive context (waived rules, unrun checks, not a design review). No filler or repetition of schema details.

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?

The tool has a rich output schema, so return-value details are already covered. The description covers the key contextual gaps: when to use it, how to interpret results (waived rules, unrun checks), and how it differs from a design review. For a read-only query tool with 100% schema coverage and an output schema, this is complete.

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 description coverage is 100%, so the schema already documents all five parameters thoroughly. The description adds value by clarifying the semantics of the 'rules' parameter ('YOUR OWN limits... never stored as if a fab had published it') and the 'vendor' parameter ('Returns geometric checks against that fab's stored profile... instead of the board's own DRC/ERC'). It also clarifies that 'category' filters violation details but counts are always returned. This goes beyond the schema's field-level descriptions.

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 states a specific verb ('returns'), a clear resource (stored DRC and ERC results for a board's current version), and explicitly distinguishes itself from a design review. It also names the sibling tool run_checks implicitly by saying 'This is not a design review,' which helps an agent differentiate it from the run_checks sibling.

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?

The description explicitly says when to use it: 'Use when the user asks whether a board passes KiCad's own checks, or before trusting a design.' It also gives a clear exclusion: 'This is not a design review,' which routes the agent away from using this tool for broader design review tasks. It further clarifies the semantics of unrun checks, which is critical for correct interpretation.

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

list_board_filesList a board's filesA

Read-onlyIdempotent

Inspect

Use when you need the exact files in a known public board (KiCad source, docs, fabrication outputs, gerbers) before read_file, or to show a project's layout. Returns paths, extensions, sizes, and roles, up to 100 per call; pass the returned cursor only when more are needed. Returns paths only, never contents. Do not guess paths; for schematic wiring prefer read_schematic, for copper vias/pads/tracks prefer read_pcb, and for parts prefer get_bom over reading raw files.

ParametersJSON Schema

Name	Required	Description	Default
`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.
`cursor`	No	Opaque pagination cursor from a previous call; pass to fetch the next page.

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`files`	Yes
`nextCursor`	Yes
`hasNextPage`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark the tool read-only and idempotent, and the description adds complementary behavior: returns up to 100 items, supports a cursor for pagination, returns metadata only and never file contents. There is no contradiction with the readOnlyHint or destructiveHint annotations.

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?

Every sentence earns its place: use case, output shape, pagination, content boundary, and routing to alternatives. The most important scoping information is front-loaded and there is no filler.

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?

With an output schema present, the safe/idempotent profile covered by annotations, and simple parameters, the description covers everything an agent needs to select and invoke this tool correctly, including exclusions and pagination behavior.

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 the schema already explains board references, cursor usage, and how to find boards. The description reinforces 'known public board' and 'only pass cursor when more are needed,' but adds limited new meaning 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 states a specific action and resource: list the exact files in a known public board. It clearly distinguishes the tool from read_schematic, read_pcb, and get_bom by explaining that this tool returns paths, not contents, and that other tools should be used for those concerns.

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?

Explicitly says when to use the tool ('before read_file' and 'to show a project's layout') and names specific alternatives for other needs. It also warns against guessing paths, which is actionable routing guidance for an agent.

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

list_fab_profilesList fabrication profilesA

Read-onlyIdempotent

Inspect

Use before get_checks(vendor: ...) to see which fab houses a board can be checked against, and exactly which limits each one is checked to (track width, clearance, drill, annular ring, edge clearance, hole spacing). Takes no board. Layer coverage is per profile and is NOT interchangeable: a fab with no profile for a board's layer count cannot answer for it, and get_checks says so rather than guessing. Do not invent a vendor id.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	Yes
`vendors`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context: takes no board, layer coverage is per profile and not interchangeable, and get_checks reports unsupported cases rather than guessing. No contradiction with annotations.

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 front-loaded with the primary use case and completes with concise caveats that directly affect correct usage. Every sentence contributes either routing, scope, or a caution; there is no filler.

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?

The description fully covers what the agent needs to use the tool correctly: when to call it, what it returns conceptually, why layer coverage matters, and what not to do. The output schema handles return-structure details, so no critical behavioral information 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 tool has zero parameters and the schema already reflects that with 100% coverage. The description reinforces the invocation context by saying 'Takes no board,' which is useful grounding even though there are no parameters to document.

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?

States a specific action ('list') on a clear resource ('fab profiles') and names the intended use with get_checks. It distinguishes itself by explaining it shows which fab houses and their limits, not just a generic list.

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

Usage Guidelines4/5

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

Explicitly instructs to use before get_checks(vendor: ...) and warns not to invent a vendor id. It provides clear when-to-use context but does not explicitly describe when-not-to-use or discuss alternatives beyond the get_checks tie-in.

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

query_designQuery a KiCad file's structureA

Read-onlyIdempotent

Inspect

Use to read a KiCad file as STRUCTURE rather than text: pass a file path from list_board_files and a select path of node names from the root, and get the matching nodes back as data. For example select ["kicad_pcb","layers"] for the layer stack, ["kicad_pcb","footprint"] for the footprints, ["kicad_pcb","via"] / ["kicad_pcb","segment"] for raw via and track nodes, ["kicad_pcb","zone"] for copper pours, ["kicad_sch","lib_symbols"] for symbol definitions, or use read_file for JSON .kicad_pro design rules and net classes. Far cheaper and more reliable than reading a multi-megabyte board as raw text with read_file. For schematic CONNECTIVITY prefer read_schematic; for copper nets, vias and pads prefer read_pcb. Use this for what those two do not carry (zones, stackup details, footprint properties, design rules).

ParametersJSON Schema

Name	Required	Description
`path`	Yes	The exact file path within the board, as returned by list_board_files. Do not guess.
`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.
`depth`	No	How many levels of children to expand (default 2). Keep it small: a deep expansion of a large board is a large response.
`cursor`	No	Opaque pagination cursor from a previous call; pass to fetch the next page of matches.
`select`	Yes	Node names from the root downward, e.g. ["kicad_pcb","layers"], ["kicad_pcb","via"], ["kicad_pcb","zone"], or ["kicad_sch","lib_symbols","symbol"]. The first entry is the file's root node.

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`path`	Yes
`select`	Yes
`matches`	Yes
`nextCursor`	Yes
`hasNextPage`	Yes
`totalMatches`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description does not need to restate safety. It adds useful behavioral context: the tool returns matching nodes as data, is cheaper and more reliable than raw text reads for large boards, and has depth-expansion costs worth controlling. This goes beyond the annotations without contradicting them.

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 long but densely useful: core usage is front-loaded, followed by concrete examples and explicit sibling-tool routing. Every sentence contributes to correct selection or invocation, and no space is wasted on restating obvious schema details.

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 full schema coverage, output schema presence, and rich annotations, the description covers what the tool does, when to use it, which siblings to prefer for other cases, and how to use the critical parameters. Nothing essential for an agent to invoke this tool correctly 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by giving concrete select path examples, tying path to list_board_files, and warning that depth expansion should be kept small. This is meaningful enrichment 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 states a specific verb and resource: query/read a KiCad file as structured data rather than raw text. It explicitly contrasts with read_file, read_schematic, and read_pcb, so an agent can distinguish this tool from siblings without opening schemas.

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?

The description provides explicit when-to-use guidance and names alternatives: use read_file for JSON .kicad_pro design rules, read_schematic for connectivity, read_pcb for copper nets/vias/pads, and this tool for zones, stackup, footprint properties, and design rules. It also tells the agent where to get the file path (list_board_files).

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

read_fileRead a board fileA

Read-onlyIdempotent

Inspect

Use when the user wants the raw contents of a specific file in a public board (a README, config, or a .kicad_sch/.kicad_pcb), by an exact path from list_board_files or one the user gave. Text returns a 128 KiB UTF-8 chunk (pass the returned nextOffset for more); binary returns a download URL, not bytes, so do not claim to have read a binary's contents. Do not guess paths. Prefer read_schematic for schematic wiring and read_pcb for copper vias/pads/tracks over parsing raw .kicad_sch/.kicad_pcb.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	The exact file path within the board, as returned by list_board_files. Do not guess.
`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.
`offset`	No	Byte offset to start a text file from (default 0); pass the returned nextOffset to continue.

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses concrete behavior: text files return a 128 KiB UTF-8 chunk with pagination via nextOffset, binary files return a download URL rather than bytes, and agents should not claim to have read binary contents. This adds valuable context not present in the schema or annotations.

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 three sentences with zero redundancy. It front-loads the purpose, then covers usage, output behavior, and alternatives efficiently. Every sentence earns its place, making it easy for an agent to parse quickly.

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 tool with 3 parameters and no output schema, the description is remarkably complete. It explains output formats (text vs binary), pagination, path constraints, and alternatives. An agent has all the information needed to correctly invoke the tool and interpret results.

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 100% for all three parameters, so the baseline is 3. The description adds meaningful clarification on the offset parameter by explaining its role in continuing pagination with nextOffset, and reinforces the 'do not guess' guidance for paths. This justifies a slight bump above baseline.

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 raw file contents from a public board, names the file types (README, config, .kicad_sch/.kicad_pcb), and differentiates itself from read_schematic and read_pcb by explicitly listing when to prefer those alternatives. This gives an agent a precise understanding of the tool's function.

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?

The description explicitly says when to use this tool (raw contents of a specific file by exact path) and when not to (prefer read_schematic for wiring, read_pcb for copper/vias/tracks). It also warns against guessing paths, providing clear conditional logic for tool selection.

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

read_pcbRead a board's PCB copperA

Read-only

Inspect

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.

ParametersJSON 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

ParametersJSON Schema

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

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.

read_schematicRead a board's schematicA

Read-only

Inspect

Use when the user asks how a public board is wired, what a component (e.g. U1) connects to, or which pins are on a net (e.g. GND), in that design. Returns the board's latest geometry-free connectivity. No focus returns a bounded overview (components + a net index); ref returns one component and the nets it connects to with the other pins on those nets; net returns the pins on that net. These are in-design connections, not an authoritative manufacturer pinout, and a very large design may be truncated (the response flags this). Prefer a focused ref or net over repeated overviews. Use get_bom for purchasing and read_file for raw source. If nets are still computing, continue with the components shown and try again shortly rather than inferring connectivity.

ParametersJSON Schema

Name	Required	Description
`net`	No	Optional. One net name (e.g. GND, USB_DP): returns the pins on it. Prefer this for 'what is on net X'. Provide at most one of ref or net.
`ref`	No	Optional. One reference designator (e.g. U1, J2): returns it plus the nets it connects to and the other pins on those nets. Prefer this over a full overview for a wiring or pin question. 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

ParametersJSON Schema

Name	Required	Description
`url`	No
`note`	No
`found`	Yes
`source`	No
`message`	No
`netCount`	No
`truncated`	No
`matchStatus`	No
`requestedNet`	No
`requestedRef`	No
`netsAvailable`	No
`componentCount`	No

TDQS

A4.9/5.0

Behavior5/5

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

The description adds meaningful behavioral context beyond annotations: results are geometry-free, reflect in-design rather than authoritative manufacturer pinout, may be truncated for very large designs (with flagging), and nets may still be computing. It is fully consistent with readOnlyHint=true and openWorldHint=true, and flags caveats that an agent must know to interpret results correctly.

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: use-case triggers, output semantics, caveats, preference guidance, sibling routing, and status handling. It is front-loaded with the most important usage trigger and maintains a clean structure that an agent can quickly scan.

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 presence of an output schema and annotations, the description covers everything needed to select and invoke the tool correctly: when to use it, what each parameter mode returns, caveats about accuracy and truncation, and fallback behavior when nets are still computing. There are no critical gaps.

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 description coverage is 100%, so the baseline is 3, but the description goes further by explaining the behavioral meaning of each calling mode: no focus returns a bounded overview, ref returns a component plus its nets and other pins, and net returns pins on that net. It also reinforces the 'at most one of ref or net' constraint with examples, adding genuine 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 and resource: reading a public board's schematic connectivity inside an EDA design, and explicitly contrasts it with siblings get_bom and read_file. It precisely distinguishes why an agent would choose this over alternatives, leaving no ambiguity.

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?

It begins with explicit triggers ('when the user asks how a public board is wired, what a component connects to, or which pins are on a net'), gives preference guidance for focused ref/net calls over overviews, names get_bom and read_file as alternatives, and explains how to handle in-progress net computation. This is comprehensive guidance.

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

run_checksRun a board's checksA

Read-only

Inspect

Use when get_checks reports the checks have not been run for this board's current version and you need a verdict before answering. Runs KiCad's own DRC and ERC, or a fab house's manufacturability rules when vendor is given (list them with list_fab_profiles). EXPENSIVE and shared: this is a real kicad-cli run on one worker that everyone's boards queue behind, so run it when the answer matters, not on every board you look at. It usually returns the result directly; on a busy queue it returns status 'running' and you read the result later with get_checks. Do not use it to re-run a board that already has a result at this version.

ParametersJSON Schema

Name	Required	Description
`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.
`rules`	No	Optional: YOUR OWN limits in millimetres, when no published fab profile fits - an in-house process, a tier a vendor does not publish, or a house rule tighter than any of them. Keys are the same limit names list_fab_profiles reports (trackWidthOuterMm, clearanceOuterMm, drillPlatedMinMm, annularMinMm and so on); values are millimetres. Mutually exclusive with vendor. The result is never stored as if a fab had published it.
`vendor`	No	Optional fab house id from list_fab_profiles. Omit to run the board's own DRC + ERC.

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	Yes
`status`	Yes
`vendor`	Yes
`pollWith`	Yes
`rulesetHash`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses that this is an expensive, shared kicad-cli run on one worker with a global queue, and that it may return status 'running' asynchronously. This is exactly the kind of behavioral context an agent needs and that annotations alone 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence earns its place: trigger condition, behavior, cost warning, return behavior, and negative instruction. The most decision-relevant information is front-loaded, and the length is justified by the amount of useful operational guidance packed in.

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?

With an output schema present, return values are already specified, and the description fills the remaining gap by explaining when results are direct vs deferred. It also covers the interaction with get_checks and list_fab_profiles, making the tool fully usable in context.

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%, so the parameters are already thoroughly documented, including the meaning of `vendor`, the format and semantics of `rules`, and mutual exclusivity. The prose description adds context about when to use `rules` but does not substantially extend the parameter meaning 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 states a specific verb and resource: it runs KiCad DRC/ERC, or a fab house's manufacturability rules when `vendor` is given. It clearly differentiates itself from get_checks by positioning itself as the action that produces a result, while get_checks reads that result later.

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?

The description gives an explicit trigger: use it when get_checks reports checks have not been run for the current version and a verdict is needed. It also names alternatives (get_checks, list_fab_profiles), warns against overuse due to cost, and explicitly says not to re-run a board that already has a result at this version.

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

search_boardSearch inside a board's filesA

Read-onlyIdempotent

Inspect

Use to find where something appears across a board's text files in ONE call, instead of reading files one by one: give a literal string (a net name, a reference designator, a part number, a footprint) and get back the file, line number and matching line for each hit. Optionally restrict to a file extension with path_suffix. Matching is literal and case-insensitive, not a regular expression. Prefer read_schematic for schematic wiring, read_pcb for copper vias/pads/tracks, and query_design for a file's structure; use this when you need to locate something by name.

ParametersJSON Schema

Name	Required	Description
`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.
`query`	Yes	The literal text to find, e.g. "USB_DP" or "ATmega328". Not a regular expression.
`max_results`	No	Optional cap on matches returned (default 100).
`path_suffix`	No	Optional. Only search files ending with this, e.g. ".kicad_sch" or ".md".

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`query`	Yes
`hasMore`	Yes
`matches`	Yes
`filesScanned`	Yes
`filesSkipped`	Yes
`bytesTruncated`	Yes
`filesTruncated`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail beyond that: matching is literal and case-insensitive, not regex, and hits return file, line number, and matching line. It does not mention rate limits or performance characteristics, but the existing coverage makes this adequate.

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?

Three sentences with no waste: the core action is front-loaded, followed by examples, matching rules, and sibling routing. Every sentence contributes distinct information and the structure makes scanning easy.

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 4-parameter search tool with an output schema and safety annotations, the description is complete. It explains what a hit returns, how matching behaves, how to limit file types, and which sibling tools cover related but different intents. Nothing essential is missing for an agent to invoke it correctly.

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 100%, so the baseline is 3. The description adds semantic value beyond the schema by giving concrete query examples ('net name, reference designator'), explaining the purpose of path_suffix ('restrict to a file extension'), and reinforcing that query is literal, not a regular expression.

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 uses a specific verb ('find where something appears') and a clear resource ('a board's text files'), with examples of what can be searched. It explicitly contrasts with reading files one-by-one and names sibling tools it is not, so an agent can distinguish it immediately.

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?

The description gives explicit when-to-use and when-not-to-use guidance: 'Prefer read_schematic for schematic wiring, read_pcb for copper vias/pads/tracks, and query_design for a file's structure; use this when you need to locate something by name.' This is direct, actionable routing.

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

search_boardsSearch public boardsA

Read-onlyIdempotent

Inspect

Use when the user wants to find real public KiCad/EDA projects: reference designs, or boards using a given component, tag, license, author, or capability (pcb, schematic, bom, gerbers). Searches BoardRepo's public corpus and returns up to 20 board summaries per page (handle/slug, name, description, tags, license, capabilities, saves, stars, URL), ranked by popularity by default so the most-trusted boards come first; pass page for more, or sort:recent for newest. Query is free text plus optional qualifiers: component:esp32 tag:keyboard license:mit has:pcb author:handle. Free-text words are ANDed, so a specific multi-word query narrows fast: if it returns nothing, do not shave one word off and retry — cut straight to the SINGLE most distinctive term (the brand, chip family, or part number) before concluding no board exists. Weigh each result by its saves/stars and completeness rather than trusting it blindly. Do not use for general electronics theory, generic datasheet facts, or the user's own local or private design. Pass a result's handle/slug or URL to get_board; do not guess a handle/slug.

ParametersJSON Schema

Name	Required	Description
`page`	No	1-based page; each page returns up to 20 boards.
`sort`	No	Result ordering: popular (default: most saved, then most GitHub-starred) or recent (newest first).
`query`	No	Free text and/or qualifiers, e.g. "esp32 keyboard component:esp32 tag:keyboard has:schematic author:alice". Free-text words are ANDed, so every extra word can only NARROW the results — measured on the live corpus, "esp32" matches 748 boards, "esp32 keyboard" 23, and "esp32 keyboard lora" 1. Start with the ONE most distinctive word (a part number, chip family, or brand) and add terms only to narrow a result set that is too large. At most 6 distinct free-text words; more is rejected. Omit to list recent public boards.

Output Schema

ParametersJSON Schema

Name	Required	Description
`hint`	No
`page`	Yes
`sort`	Yes
`total`	Yes
`boards`	Yes
`hasNextPage`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already mark read-only/idempotent, and the description adds default ranking, pagination cap of 20, ANDed free-text semantics, qualifier syntax, and a caveat to weigh results by saves/stars. No contradiction with annotations.

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 front-loaded with the use case, then output/behavior, query semantics, and strategy. Every sentence adds distinct value, and the organization matches an agent's decision flow. Slightly dense but not padded.

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 rich input schema and existing output schema, the description covers pagination, sorting, qualifiers, defaults, and edge-case handling (empty results). Nothing an agent needs to invoke this correctly is missing.

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

Parameters5/5

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

Although the schema has 100% coverage, the description adds substantial meaning: qualifier syntax (component:, tag:, license:, has:, author:), AND semantics, the 6-word limit, and a search optimization strategy ('cut straight to the SINGLE most distinctive term'). This goes far beyond the schema description.

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 description states a clear verb ('Searches') and resource (BoardRepo's public corpus), and specifies the project types and returned fields. However, it does not explicitly differentiate from the sibling 'search_board', so the agent must infer the plural/scope distinction.

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

Usage Guidelines4/5

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

Opens with an explicit 'Use when...' and describes the intended user goal, and it gives a concrete query strategy for handling empty results. It stops short of naming alternatives or when-not conditions, so it is clear context but no exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 26, 2026

Changedget_board1 field changed

changedOutput schema / oneOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "board": {
-        "type": "string"
-      },
-      "found": {
-        "const": false
-      },
-      "message": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "found",
-      "board",
-      "message"
-    ],
-    "type": "object"
-  },
-  {
-    "additionalProperties": true,
-    "properties": {
-      "capabilities": {
-        "additionalProperties": false,
-        "properties": {
-          "bom": {
-            "type": "boolean"
-          },
-          "gerbers": {
-            "type": "boolean"
-          },
-          "pcb": {
-            "type": "boolean"
-          },
-          "schematic": {
-            "type": "boolean"
-          }
-        },
-        "required": [
-          "schematic",
-          "pcb"
-        ],
-        "type": "object"
-      },
-      "createdAt": {
-        "type": "string"
-      },
-      "downloadCount": {
-        "type": "integer"
-      },
-      "fileCount": {
-        "type": "integer"
-      },
-      "found": {
-        "const": true
-      },
-      "handle": {
-        "type": "string"
-      },
-      "name": {
-        "type": "string"
-      },
-      "saveCount": {
-        "type": "integer"
-      },
-      "slug": {
-        "type": "string"
-      },
-      "updatedAt": {
-        "type": "string"
-      },
-      "url": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "found",
-      "handle",
-      "slug",
-      "name",
-      "capabilities",
-      "fileCount",
-      "downloadCount",
-      "saveCount",
-      "createdAt",
-      "updatedAt",
-      "url"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "board": {
+        "type": "string"
+      },
+      "found": {
+        "const": false
+      },
+      "message": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "found",
+      "board",
+      "message"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": true,
+    "properties": {
+      "capabilities": {
+        "additionalProperties": false,
+        "properties": {
+          "bom": {
+            "type": "boolean"
+          },
+          "gerbers": {
+            "type": "boolean"
+          },
+          "pcb": {
+            "type": "boolean"
+          },
+          "schematic": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "schematic",
+          "pcb"
+        ],
+        "type": "object"
+      },
+      "createdAt": {
+        "type": "string"
+      },
+      "downloadCount": {
+        "type": "integer"
+      },
+      "fileCount": {
+        "type": "integer"
+      },
+      "found": {
+        "const": true
+      },
+      "handle": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "saveCount": {
+        "type": "integer"
+      },
+      "slug": {
+        "type": "string"
+      },
+      "stars": {
+        "type": "integer"
+      },
+      "updatedAt": {
+        "type": "string"
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "found",
+      "handle",
+      "slug",
+      "name",
+      "capabilities",
+      "fileCount",
+      "downloadCount",
+      "saveCount",
+      "createdAt",
+      "updatedAt",
+      "url"
+    ],
+    "type": "object"
+  }
+]

3 tool updatesSep 16, 2026

Changedget_checks1 field changed

changedInput schema / properties / vendor / description

Previous value: -"Optional fab house id from list_fab_profiles. Returns that fab's manufacturability verdict for this board instead of the board's own DRC/ERC. Do not invent an id."New value: +"Optional fab house id from list_fab_profiles. Returns geometric checks against that fab's stored profile for this board instead of the board's own DRC/ERC. Do not invent an id."

Changedquery_design1 field changed

changedInput schema / properties / select / description

Previous value: -"Node names from the root downward, e.g. [\"kicad_pcb\",\"layers\"] or [\"kicad_sch\",\"lib_symbols\",\"symbol\"]. The first entry is the file's root node."New value: +"Node names from the root downward, e.g. [\"kicad_pcb\",\"layers\"], [\"kicad_pcb\",\"via\"], [\"kicad_pcb\",\"zone\"], or [\"kicad_sch\",\"lib_symbols\",\"symbol\"]. The first entry is the file's root node."

Addedread_pcb

1 tool updateSep 16, 2026

Changedget_checks1 field changed

changedInput schema / properties / vendor / description

Previous value: -"Optional fab house id. Returns that fab's manufacturability verdict for this board instead of the board's own DRC/ERC. Do not guess an id - if your tool list includes one for listing fab profiles, get the id from there; if it does not, use `rules` with explicit millimetre limits instead."New value: +"Optional fab house id from list_fab_profiles. Returns that fab's manufacturability verdict for this board instead of the board's own DRC/ERC. Do not invent an id."

9 tool updatesSep 14, 2026

Changedget_board1 field changed

changedInput schema / properties / board / description

Previous value: -"A public board: handle/slug (e.g. alice/keezyboost40) or a boardrepo.com URL. Discover it with search_boards; do not invent one."New value: +"A board: handle/slug or a boardrepo.com URL. Discover public boards with search_boards, personal or authorised organisation boards with list_my_boards."

Changedget_bom1 field changed

changedInput schema / properties / board / description

Previous value: -"A public board: handle/slug (e.g. alice/keezyboost40) or a boardrepo.com URL. Discover it with search_boards; do not invent one."New value: +"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."

Changedget_checks1 field changed

changedInput schema / properties / board / description

Previous value: -"A public board: handle/slug (e.g. alice/keezyboost40) or a boardrepo.com URL. Discover it with search_boards; do not invent one."New value: +"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."

Changedlist_board_files1 field changed

changedInput schema / properties / board / description

Previous value: -"A public board: handle/slug (e.g. alice/keezyboost40) or a boardrepo.com URL. Discover it with search_boards; do not invent one."New value: +"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."

Changedquery_design1 field changed

changedInput schema / properties / board / description

Previous value: -"A public board: handle/slug (e.g. alice/keezyboost40) or a boardrepo.com URL. Discover it with search_boards; do not invent one."New value: +"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."

Changedread_file1 field changed

changedInput schema / properties / board / description

Previous value: -"A public board: handle/slug (e.g. alice/keezyboost40) or a boardrepo.com URL. Discover it with search_boards; do not invent one."New value: +"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."

Changedread_schematic1 field changed

changedInput schema / properties / board / description

Previous value: -"A public board: handle/slug (e.g. alice/keezyboost40) or a boardrepo.com URL. Discover it with search_boards; do not invent one."New value: +"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."

Changedrun_checks1 field changed

changedInput schema / properties / board / description

Previous value: -"A public board: handle/slug (e.g. alice/keezyboost40) or a boardrepo.com URL. Discover it with search_boards; do not invent one."New value: +"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."

Changedsearch_board1 field changed

changedInput schema / properties / board / description

Previous value: -"A public board: handle/slug (e.g. alice/keezyboost40) or a boardrepo.com URL. Discover it with search_boards; do not invent one."New value: +"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."

1 tool updateSep 8, 2026

Changedsearch_board2 fields changed

addedOutput schema / properties / bytesTruncated
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / required

Previous value: -[
-  "query",
-  "matches",
-  "filesScanned",
-  "filesSkipped",
-  "filesTruncated",
-  "hasMore"
-]New value: +[
+  "query",
+  "matches",
+  "filesScanned",
+  "filesSkipped",
+  "filesTruncated",
+  "bytesTruncated",
+  "hasMore"
+]

1 tool updateAug 29, 2026

Changedsearch_boards2 fields changed

changedInput schema / properties / query / description

Previous value: -"Free text and/or qualifiers, e.g. \"esp32 keyboard component:esp32 tag:keyboard has:schematic author:alice\". Omit to list recent public boards."New value: +"Free text and/or qualifiers, e.g. \"esp32 keyboard component:esp32 tag:keyboard has:schematic author:alice\". Free-text words are ANDed, so every extra word can only NARROW the results — measured on the live corpus, \"esp32\" matches 748 boards, \"esp32 keyboard\" 23, and \"esp32 keyboard lora\" 1. Start with the ONE most distinctive word (a part number, chip family, or brand) and add terms only to narrow a result set that is too large. At most 6 distinct free-text words; more is rejected. Omit to list recent public boards."

addedOutput schema / properties / hint
```
Added value: +{
+  "type": "string"
+}
```

4 tool updatesAug 27, 2026
- Removedget_findings
- Removedlist_my_boards
- Removedreview_board
- Removedverify_claim
15 tool updatesAug 27, 2026
- First observedget_board
- First observedget_bom
- First observedget_checks
- First observedget_findings
- First observedlist_board_files
- First observedlist_fab_profiles
- First observedlist_my_boards
- First observedquery_design
- First observedread_file
- First observedread_schematic
- First observedreview_board
- First observedrun_checks
- First observedsearch_board
- First observedsearch_boards
- First observedverify_claim

Related MCP Connectors

partreel A
io.github.mingyo186
Verified KiCad footprints, symbols & 3D models for AI agents. No signup, CC-BY-4.0, quality-gated.
Embedded system Developer Tools
72
catalog A
ai.partsgraph
Search real parts with datasheet-provenance specs, check compatibility and compose priced BOMs.
Search E-commerce & Retail
111
Source PartsOAuth
io.github.SourceParts
Electronic component sourcing, BOM management, and PCB design workflows.
Developer Tools App Automation Product Management
22
Whatic IC Datasheets A
io.whatic
IC datasheet search: parametric part finding, spec lookup, price comparison — grounded in real PDFs.
Embedded system Documentation Access
72

Related MCP Servers

KiCad MCP Server
Developer Tools Software Architecture Embedded system
bleugreen
A
license
A
quality
C
maintenance
Enables analysis of KiCad electronic schematics through natural language queries to search components, trace signal paths, explore connections, and analyze multi-board systems.
Updated 3 months ago (2026-07-04 05:14 UTC)
30
1
MIT
kicad-mcp
RAG Systems Design Tools
fsbondtec
A
license
Not graded
quality
C
maintenance
Enables natural language interaction with KiCad projects, schematics, and PCBs, supporting project management, design rule checking, netlist extraction, and datasheet RAG search.
Updated a month ago (2026-08-18 06:04 UTC)
2
MIT
KiCad MCP Server
Developer Tools Search Documentation Access
skeptomai
A
license
Not graded
quality
D
maintenance
Enables natural language search and exploration of KiCad component symbol libraries with fast full-text search across 20,000+ components including metadata like datasheets, footprints, and descriptions.
Updated 10 months ago (2025-12-08 17:45 UTC)
MIT
mcp-pcb-emcopilot
Developer Tools Testing & QA Tools
RFingAdam
A
license
C
quality
B
maintenance
AI-powered PCB design review MCP server with 93 tools for EMC, signal integrity, power integrity, thermal, and DFM analysis, supporting KiCad, ODB++, Gerber, and more, and generating audit-grade DOCX/HTML reports.
Updated a month ago (2026-09-01 03:08 UTC)
100
3
AGPL 3.0

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.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources