MCP server for EDA tool automation, currently supports Altium Designer. Around 400 tools for schematic, PCB, and library ops via DelphiScript bridge.
28 tools with highly inconsistent quality. Tool names lack clear action verbs (tool_catalog, tool_guide, tool_invoke are generic; design_execute_plan, easyeda_emit_plan use unclear verbs). Most descriptions are present but terse (10-50 chars), below the 50-200 char LLM-optimized baseline. Input schemas visible for most tools but many lack parameter descriptions or type constraints. No output schemas documented. Error handling and recovery guidance absent. Composition is reasonable (single responsibility mostly observed) but parameter naming inconsistencies (e.g., 'plan' object with no schema detail) force LLMs to guess structure.
Execute a DesignPlan to place and route a schematic in one call (Altium only)
Read current component positions from a schematic as placement hints
Return a DesignPlan layout as data without touching the EDA
Read a DesignPlan back off an existing schematic
Render a DesignPlan layout as an image preview
Add wires to an EasyEDA schematic
Apply a DesignPlan to an EasyEDA schematic (EasyEDA only)
Get the capabilities of the EasyEDA API
Descriptions are uniformly terse (10-50 chars), far below the 50-200 char LLM-optimized baseline. Examples: 'Core tool: review the current design for issues and get a summary' (67 chars) lacks WHEN to use it, WHAT prerequisites exist, or WHAT the output contains. LLMs cannot reliably select tools without richer context.
Complex object parameters ('plan', 'components', 'wires') lack schema detail. design_execute_plan accepts a 'plan' object but no schema shows what fields it requires (e.g., does it need component_id, position, rotation?). LLMs cannot construct valid payloads without explicit field documentation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | <=2025-11-25 | v2 |
Get environment information from EasyEDA
Get measured shape information from EasyEDA
Get project information from EasyEDA
Place components on an EasyEDA schematic
Review the current EasyEDA board
Take a snapshot of the current EasyEDA design for review
Core tool: get information about the current board
Create a new footprint in a library
Create a new symbol in a library
Core tool: list all components in the current design
Core tool: list all nets in the current design
Place components on a PCB (Altium only)
Core tool: review the current design for issues and get a summary
Core tool: run design rule check on the current board
Core tool: run electrical rule check on the current schematic
Place components on a schematic (Altium only)
Place wires on a schematic (Altium only)
Search and browse the tool surface by name, category, or interaction class
Get detailed guidance on a specific tool, including what it needs first, related tools, and limitations
Invoke any tool by name with arguments, used when tool_catalog and tool_guide are the only advertised tools (minimal toolset)
No output schemas documented for any tool. Agents cannot plan downstream calls or extract required fields (e.g., does list_components return component_id, reference_designator, value?). This forces agents to guess structure and wastes tokens on clarification.
Generic tool names reduce clarity. 'tool_catalog', 'tool_guide', 'tool_invoke' are meta-tools that describe other tools, but their names do not signal this. Rename to 'search_tools', 'describe_tool', 'invoke_tool' or similar to clarify intent. 'design_execute_plan' and 'easyeda_emit_plan' use unclear verbs, 'apply_design_plan' or 'execute_design_plan' would be clearer.
No error handling or recovery guidance. Tools return no documented error cases, retryability, or next steps. If run_drc fails, the agent has no guidance on whether to retry, check prerequisites, or call a different tool. This violates the recovery-guide pattern.