Loading ToolBench
MCP server exposing Perfboard Studio to coding agents (stdio + streamable HTTP). Design circuits on pad-per-hole perfboard, verify connectivity, and produce soldering guides.
Perfboard Studio MCP exhibits significant definition quality gaps. Tool naming is generally verb-based (get_, list_, render_) but descriptions vary widely in quality and completeness. Critical issues: (1) Duplicate tool definitions (get_board_info, list_components, get_component, get_nets appear twice with different schemas/descriptions), creating ambiguity for LLM selection. (2) Many parameter descriptions are missing or trivial, e.g., render_2d_view's 'px_per_mm' lacks guidance on valid ranges or typical values. (3) Output schemas are not documented in the tool definitions; LLMs cannot predict response structure. (4) Error handling is absent, no guidance on recovery, retryability, or what to do when a component is not found. (5) Some descriptions are overly verbose and narrative (render_schematic) rather than concise and action-oriented. Baseline: avg tool description 194 chars; this server's descriptions range 50 - 400+ chars with inconsistent structure. No tool annotations (readOnlyHint, destructiveHint) despite all tools being read-only.
Board type, dimensions (in holes and mm), pitch, material, pad/drill diameter and hole count for the current document.
The board itself: grid size, pitch, thickness, material, and the hole addresses of its corners.
Look up a single component by ref (e.g. "R1") or id, with its full detail. Returns an error result, not an exception, if no matching component exists.
One part in full, including which hole each of its pins sits in.
Document metadata: format version, name, component/net/cut/conductor counts, and a breakdown of conductor kinds.
What the board actually joins for one net, which pins are still in separate islands, and the connections that remain to be made.
Duplicate tool definitions: get_board_info, list_components, get_component, and get_nets are defined twice with different schemas and descriptions. This creates ambiguity for LLM tool selection and violates single-responsibility principle.
Output schemas are not documented. LLMs cannot predict response structure, field names, or types. This forces agents to guess at downstream tool parameters and risks broken tool chains.
Parameter descriptions are missing or incomplete. render_2d_view's 'px_per_mm' lacks range guidance; list_footprints' 'search' lacks examples or format hints. LLMs cannot infer valid input ranges.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | <=2025-11-25 | v2 |
The schematic's nets — what the circuit is SUPPOSED to connect. What the board actually connects is a different question; ask get_net_connections.
The schematic's nets — what the circuit is SUPPOSED to connect. What the board actually connects is a different question; ask get_net_connections.
Where this board stands: part and net counts, DRC and LVS summaries, how many connections are still unrouted, and how deep the undo stack is. Call this first, and again after anything that surprises you.
List the components placed on the board: id, ref, value, footprint, anchor position (grid + "A1"-style) and orientation. Optionally filter by a case-insensitive substring match against ref or value.
Every part on the board with its reference, value, footprint, anchor hole, rotation and whether it is locked.
The parts library. Free text matches the id, the name or the body type — try "dip", "resistor", "electrolytic", or leave it empty for all of them. A part that is NOT in this list can still be used: ask for one by its measurements instead of its name. Placing an id nothing recognises returns the grammar for that, which is where it is spelled out rather than here — it is a page long and only matters once.
A picture of the board as the editor draws it. side="top" is the component side; side="bottom" is the solder side as you would see it holding the board up — mirrored, showing pads, cut lead ends and the copper, with no component bodies, because on a real board the parts are on the far face.
A picture of the CIRCUIT: symbols, wires, junctions, ground and power glyphs. What the board is a way of BUILDING, drawn from the nets themselves. Use it after wiring to check that what you connected is the circuit you meant — the board renders show copper, which is what the circuit was turned into, not what it is. The sheet is generated from the document every time unless somebody has drawn on it in the application, and either way there is no second answer to what is connected: what a hand-drawn wire JOINS is still whichever net holds both of its ends.
No error handling guidance. Tools lack recovery hints (e.g., 'Component not found. Try list_components() to see available refs.'). Agents cannot self-correct on failures.
No tool annotations. All tools are read-only but lack readOnlyHint annotation. This prevents clients from optimizing caching or safety policies.