Coppermind
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Logging level (e.g., info, debug, warning). | info |
| COPPERMIND_BACKEND | No | Backend selection: 'auto' (default, IPC if available else memory), 'ipc' (requires live KiCAD), or 'memory' (dev/offline). | auto |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| project_createB | Create a project and initialize its board, schematic and semantic Circuit IR. |
| component_addC | Add a component from a real KiCad symbol; no coordinates are required. |
| connect_pinsA | Connect semantic pins such as ['U1.3', 'R1.1'] to an existing net. |
| create_netC | Create a named semantic net in the Circuit IR. |
| inspect_componentB | Inspect a Circuit IR component, its real pins and current net membership. |
| find_symbolC | Search installed/project KiCad libraries for real symbols. |
| design_previewA | Compose, visually review, run ERC and preview all pending changes before commit. |
| design_commitC | Compose + visual-review + ERC-gate the schematic, then commit semantic state. |
| design_rollbackA | Discard pending PCB and semantic Circuit IR changes. |
| list_tool_categoriesA | List routed tool categories and how many tools each holds. |
| get_category_toolsA | List the routed tools in a category (name + one-line summary). |
| search_toolsA | Find routed tools whose name or summary matches a keyword. |
| get_tool_schemaC | Fetch the full schema (parameters) for a single routed tool. |
| execute_toolC | Run a routed tool by name with the given arguments. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| board_preview | Live SVG preview of the current board (committed state). |
TDQS
Scored across 14 tools
Most domain tools target distinct actions (create project, add component, create net, connect pins, inspect, commit, rollback), and the meta tools are also separable. The main ambiguities are design_preview vs design_commit, whose descriptions both start with compose/review/ERC, and execute_tool, which sounds like a generic way to run any of the domain tools.
All names are snake_case, but the verb/object order is inconsistent: project_create, component_add, design_commit, and design_rollback are object-first while connect_pins, create_net, inspect_component, find_symbol, and the meta tools are verb-first. The names are understandable, but there is no single predictable pattern.
14 tools is within the typical well-scoped range, so the count is not excessive. It is slightly inflated by five meta/discovery tools that support a routed-tool system rather than directly adding circuit-design capability.
The core workflow from project creation through net creation, pin connection, review, commit, and rollback is covered. However, there are no granular update/delete/disconnect operations for components or nets, and no project listing/loading beyond creation, so the advertised surface has notable gaps.