Skip to main content
Glama
PCB Parts MCP Server

PCB Parts MCP Server

by Averyy

Get Reference Board

board_get
Read-onlyIdempotent

Retrieve detailed PCB reference board data by slug, including focused IC pin neighborhoods, cross-board wiring consensus, part numbers, and optional BOM or netlist details.

Instructions

A reference board from board_search. With focus=IC it returns that IC's pin-by-pin neighborhood (decoupling, pull-ups, connected parts) and, when 2+ boards use the IC, how the others wire it. Reply: focus_match_type says exact, partial or ref matching; consensus compares wiring across consensus.board_count boards; passives_omitted counts hidden plain passives. Components and a focused IC carry the design files' own part numbers where listed (mpn, manufacturer, lcsc, mouser, digikey): look them up with jlc_get_part or mouser_get_part. An unknown slug's error adds did_you_mean (boards sharing most of its words).

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": {
      "slug": "<slug>"
    },
    "name": "board_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYesBoard slug from board_search (e.g., "adafruit-esp32-s3-feather")
focusNoIC name (e.g., "MCP73831"; partial match: "ESP32" finds "ESP32-S3"), or any part's ref ("U3", "J1", "D2") or value words ("USB-C" finds the receptacle; connectors first): returns its pin neighborhood instead of the component list. Ground and supply pins are in power_pins: the net, with its parts when few (VBUS through a fuse) or part_count (GND); pins_in_nets counts the part's pins in the netlist; pin_count is the part's own pin count and nc_pins its pins on no net, by pad ({"I/O1": "1"}: left unconnected, a design decision; {} = all connected), where the design files give the footprint's pins (most parts with 3+ pins); pin_nets names each pin's net (numbered pins say what they are: an ESP32 module's "3" is CHIP_PU). A focus matching nothing lists available_ics and available_refs
include_bomNoAlso list plain passives (R/C/L); by default only ICs, connectors and annotated passives (the rest are counted in passives_omitted)
include_netsNoAdd the full netlist, positions and copper pours (can be 100 KB+)

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.21

TDQS

A3.6/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), so the description correctly spends its words on behavior: focus_match_type semantics (exact/partial/ref), consensus across consensus.board_count boards, passives_omitted accounting, and error behavior where an unknown slug returns did_you_mean candidates. It does not restate the return payload's shape in full, and it omits the include_nets size hazard that appears only in the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The content is dense and front-loaded, but it is delivered as one long run-on paragraph mixing calling guidance, return-field explanations, and next-step tool routing. Several clauses (focus neighborhood behavior) duplicate what the input schema already documents, which dilutes rather than concentrates the signal.

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 and full schema coverage, the description carries only what structured fields cannot: cross-board consensus behavior, passive omission accounting, error recovery hints, and hand-off to part-lookup tools. That is nearly complete for a read-only retrieval tool, with the include_nets cost (100 KB+) left to the schema.

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 baseline is 3, and the schema already spells out the focus matching modes, power_pins, nc_pins and pin_nets in more detail than the description does. The description adds only framing value (that focus returns a neighborhood 'instead of the component list') and repeats semantics the schema already carries.

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?

Opens with 'A reference board from board_search' and then characterizes the focus=IC mode precisely (pin-by-pin neighborhood, cross-board consensus), which is enough for an agent to know this retrieves a board's component/net detail. The opening is an elliptical noun phrase rather than an explicit verb, but the resource and its relationship to the sibling board_search are unambiguous.

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 rather than stated: the slug comes 'from board_search', and MPN-bearing components should be looked up 'with jlc_get_part or mouser_get_part', which routes the agent onward. However there is no explicit when-to-use/when-not guidance versus board_search, and no description-side explanation of when to enable include_bom or include_nets (that lives only in the schema).

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