Skip to main content
Glama
Sign In
PCB Parts MCP Server

PCB Parts MCP Server

by Averyy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Search Reference Boards

board_search
Read-onlyIdempotent

Search open-source reference board schematics to see how real designs implement an IC, including passives, decoupling, pull-ups, and power topology before retrieving pin-level details.

Instructions

Search ~300 open-source reference board schematics to see how real designs use an IC: its passives, decoupling, pull-ups and power topology. Not for buying parts (jlc_search) or choosing sensors (sensor_recommend). Then call board_get(slug, focus=IC) for that IC's pin-by-pin neighborhood.

Use component= for an IC name (searches the BOMs; when 2+ boards match it adds a cross-board consensus), query= for a function ("motor driver", "USB power delivery"), tag= to browse. Tags ignore case/whitespace; usb-c means usb. Unknown tags return valid_values from the catalog. Combine them to narrow. Results are sorted by relevance, then component count; matched_by says why each appeared (key IC, component, text, tag). A component consensus counts distinct boards per pin choice (pct divides by consensus.board_count); browsing by tag alone adds tag_consensus, the ICs boards in that category commonly use. An empty reply's hint names the words no board matches and what leaving them out finds.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "board_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
orgNoOrganization (e.g., "Adafruit", "SparkFun", "Olimex", "Seeed Studio", "Espressif" for its own DevKits, "Raspberry Pi")
tagNoOne tag or a list (AND), exact names, e.g. power-supply, sensors, motor-control, adc-dac, audio, rf-sdr, isolation, battery-charging, can-bus, display, inverter, led-driver, level-shifting, signal-conditioning, usb, usb-pd, ethernet, wifi, bluetooth, lora, gps-gnss, video, drone-uav, esd-protection, fpga, battery-management, current-sensing, energy-harvesting, relay, robotics, rs485, 3d-printer
limitNoMax results (max 50)
queryNoFree text over name, description, key coverage, ICs, tags and org (e.g., "ESP32 battery", "motor driver")
layersNoPCB layer count (e.g., 2, 4, 6, 8)
componentNoIC or part (e.g., "DRV8825", "STM32F4", "MCP73831")

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.21

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: sort order (relevance, then component count), what matched_by means, how cross-board consensus and tag_consensus are computed, and that unknown tags return valid_values from the catalog. Some of this overlaps the output schema, which is why it is not a 5.

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?

Front-loaded with purpose, constraints next, then parameter guidance, then result semantics ā€” a sensible ordering with no filler sentences. It is dense and slightly run-on in the consensus sentence ("pct divides by consensus.board_count"), which costs a point.

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 6-parameter, all-optional search tool with an output schema and full annotations, the description covers the gaps that matter: what each filter does, how filters compose, how ranking works, and what an empty result means. 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.

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 earns above that by explaining tag semantics the schema does not (case and whitespace insensitive, usb-c treated as usb, AND behavior when a list is passed) and by noting that combining parameters narrows results. The component/query split is clarified in a way the schema alone leaves ambiguous.

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 verb and resource with scope: "Search ~300 open-source reference board schematics to see how real designs use an IC". It immediately distinguishes itself from two named siblings (jlc_search for buying parts, sensor_recommend for choosing sensors) and points forward to board_get.

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-not guidance with named alternatives, plus per-parameter routing guidance (component= for an IC name, query= for a function, tag= to browse) and an instruction to follow up with board_get(slug, focus=IC). An agent knows both which tool to pick and which parameter to reach for.

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

Deploy Server

Other Tools