Koppar

Import a KiCad project

import_kicad_project

Bring an existing KiCad project in as a board workspace: the project folder as a ZIP (the .kicad_pcb, .kicad_pro, schematics, footprint and 3D-model folders), base64-encoded, up to about 18 MB zipped. The CLI does this with koppar import <folder>. Or from_design_id: the KiCad project of a design the pipeline built (its board, rules, schematics and custom footprints) opened as a workspace, to change the design rules, place and route it with the board tools and put the result back with upload_board (workspace_id). Returns the design_id the board tools take and a first get_board_info.

Input Schema

Name	Required	Description
`brief`	No	A note for the design record. No tool reads it: what to keep, widths and layers go in the options of set_design_rules and route_board.
`title`	No
`board_file`	No	Which .kicad_pcb at the top of the project, when there are several.
`session_id`	No	The project (web session) a new revision of this board goes into: the session_id the first import returned. Without it, an import whose title matches a project you opened before joins that project, so revisions of one board stay together in the user's list.
`zip_base64`	No	The zipped project folder, base64.
`new_project`	No	Start a new project even when one with this title exists.
`from_design_id`	No	A design of yours with a board (start_board or upload_board): its KiCad project becomes the workspace. Instead of zip_base64.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

changedInput schema / properties / brief / description

Previous value: -"What the user wants done with the board, for the design record."New value: +"A note for the design record. No tool reads it: what to keep, widths and layers go in the options of set_design_rules and route_board."

Changed2 schema fields changedNov 2, 2026

addedInput schema / properties / new_project

Added value: +{
+  "description": "Start a new project even when one with this title exists.",
+  "type": "boolean"
+}

addedInput schema / properties / session_id

Added value: +{
+  "description": "The project (web session) a new revision of this board goes into: the session_id the first import returned. Without it, an import whose title matches a project you opened before joins that project, so revisions of one board stay together in the user's list.",
+  "pattern": "^[A-Za-z0-9_-]{8,80}$",
+  "type": "string"
+}

Changed2 schema fields changedOct 18, 2026

addedInput schema / properties / from_design_id

Added value: +{
+  "description": "A design of yours with a board (start_board or upload_board): its KiCad project becomes the workspace. Instead of zip_base64.",
+  "pattern": "^[A-Za-z0-9_-]{8,80}$",
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "zip_base64"
-]
```

First observedOct 17, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare this is a non-read-only, non-destructive, non-open-world operation, so the bar is lower; the description still adds real behavior: an ~18 MB zipped payload limit, base64 encoding requirement, the folder contents expected, and the return value (design_id plus a first get_board_info). It does not discuss failure modes for oversized or malformed archives, which would have pushed it to 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?

Two sentences, both front-loaded and free of filler, with the input-mode split established early. The heavy nested parentheses and long run-on structure make it denser than necessary for a tool an agent must parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly fills that gap by stating what comes back (design_id and an initial get_board_info), and it covers both input modes and the size ceiling for a 7-parameter import tool. The absence of any note on which of the seven parameters are required, or what happens when both zip_base64 and from_design_id are supplied, is the main remaining hole.

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?

With 86% schema coverage the baseline is 3, but the description adds meaning the schema does not: zip_base64 and from_design_id are presented as mutually exclusive input paths, and the ZIP is explained as a whole project folder rather than a bare board file. It never mentions board_file or new_project in prose, so those rely entirely on their schema descriptions.

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?

"Bring an existing KiCad project in as a board workspace" names a specific verb and resource, then immediately splits into the two input modes (ZIP folder vs. from_design_id), so the agent knows exactly what the tool produces (a workspace plus a design_id). It is clearly distinguishable from start_board (new board) and upload_board (pushing a board back).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states when to use each mode: a ZIP when the user has an existing folder on disk, and from_design_id when the goal is to change rules, place and route, and return the result via upload_board. It also explains the session_id revision-grouping rule. It lacks an explicit "do not use this if…" exclusion (e.g. when to use start_board or create_design instead), keeping it short of a 5.

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

All Koppar tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?