Skip to main content
Glama
Sign In

Koppar

by ai.koppar.app
OverviewDiscussionsAdmin

Upload a board

upload_board

Replace the design's board with a .kicad_pcb you routed or edited yourself (the file, base64). The board must carry the design's circuit: every schematic part by reference, every pad on the net the netlist gives it; a footprint swap is allowed and recorded. Anything else is refused with the list of differences and nothing changes. The previous board is kept as circuit.before-upload.kicad_pcb. KiCad DRC judges the new board and releases or withholds the Gerbers, and the session chat gets a note of the upload. Not for a board workspace (import_kicad_project): its board tools edit the board in place.

Input Schema

NameRequiredDescriptionDefault
noteNoWhat was done to the board, for the session chat.
design_idYesThe design id returned by create_design or list_designs.
board_base64NoThe .kicad_pcb file, base64 (or give workspace_id).
rules_base64NoThe .kicad_dru beside the board, base64.
workspace_idNoA board workspace of yours (import_kicad_project, e.g. one made from this design with from_design_id): its board, project rules and .kicad_dru are taken from there, no download and upload.
project_base64NoThe .kicad_pro beside the board, base64: its design rules and net classes judge the board (without it the design keeps its own).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / board_base64 / description
      Previous value: -"The .kicad_pcb file, base64."New value: +"The .kicad_pcb file, base64 (or give workspace_id)."
    • addedInput schema / properties / project_base64
      Added value: +{
+  "description": "The .kicad_pro beside the board, base64: its design rules and net classes judge the board (without it the design keeps its own).",
+  "maxLength": 24000000,
+  "type": "string"
+}
    • addedInput schema / properties / rules_base64
      Added value: +{
+  "description": "The .kicad_dru beside the board, base64.",
+  "maxLength": 24000000,
+  "type": "string"
+}
    • addedInput schema / properties / workspace_id
      Added value: +{
+  "description": "A board workspace of yours (import_kicad_project, e.g. one made from this design with from_design_id): its board, project rules and .kicad_dru are taken from there, no download and upload.",
+  "pattern": "^[A-Za-z0-9_-]{8,80}$",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "design_id",
-  "board_base64"
-]New value: +[
+  "design_id"
+]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations are generic (readOnlyHint=false, destructiveHint=false) and the description adds the real behavioral profile: validation against the netlist, refusal with a difference list and no change on mismatch, footprint swaps allowed and recorded, prior board preserved as circuit.before-upload.kicad_pcb, DRC gating Gerber release, and a chat note. This is exactly the kind of side-effect and failure-mode disclosure that annotations cannot carry, and it is consistent with destructiveHint=false since the prior board is archived.

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?

Information-dense and front-loaded: the action and input come first, then constraints, side effects, and the sibling exclusion. Every clause carries content, though the long semicolon-chained sentences make it slightly heavy to parse.

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

Completeness5/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 covers what an agent needs: inputs, validation behavior, failure output (difference list), preserved artifacts, downstream DRC/Gerber consequences, and the alternative tool. Nothing material is missing for a mutation tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters are already documented in the schema (including the board_base64/workspace_id alternative). The description corroborates ('the file, base64') and implies relationships (circuit must match the netlist, footprint swap allowed) but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ('Replace the design's board with a .kicad_pcb you routed or edited yourself') and explicitly names the sibling it is not (import_kicad_project). An agent can distinguish it from the many board-editing siblings without opening a schema.

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

Usage Guidelines5/5

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

Gives an explicit exclusion with the alternative: 'Not for a board workspace (import_kicad_project): its board tools edit the board in place.' It also states the precondition that the board must carry the design's circuit, so the when/when-not conditions are fully specified.

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

All Koppar toolsInspect
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