Loading ToolBench
MCP server that lets Claude Code design KiCAD PCBs by editing project files.
Only one tool visible in source: 'ping'. It has a basic description ('Health check. Returns 'pong' if the server is reachable.') and empty input schema ({}). The server imports 17 tool registration modules (project, library, schematic, sourcing, pcb, routing, validation, manufacturing, rules, sync, library_create, signal_integrity, thermal, rf, emc, panelization, spice, simulation) but their definitions are not visible in the provided code, they are inferred from import statements only. The single visible 'ping' tool scores low because: (1) it is a health check, not a domain tool; (2) no input parameters are documented despite the schema being empty; (3) no output schema is documented. The server appears to be a comprehensive KiCAD design automation framework (phases 0 - 15 outlined in docstring), but without access to the actual tool implementations in those modules, we cannot assess their naming, descriptions, parameter schemas, or error handling. This is a major gap for evaluation.
Health check. Returns 'pong' if the server is reachable.
Only 1 of ~100+ tools visible in source code. 17 tool registration modules imported but their definitions not provided. Cannot evaluate naming, descriptions, schemas, or error handling for the vast majority of the server's functionality.
No output schema documented for ping or any visible tool. LLMs cannot plan downstream calls or extract structured data without knowing return types.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 28 | <=2025-11-25 | v2 |
No error handling guidance visible. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible. LLMs cannot determine which tools are safe to retry or have side effects.