Skip to main content
Glama
Sign In
Copper

Copper

by claynicholson
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Create project

project_create

Create a new KiCad project with schematic and PCB files, then make it active. Refuses to overwrite existing projects; supports layer templates, fab design rules, and a board outline size.

Instructions

Create a new KiCad project (.kicad_pro, .kicad_sch, .kicad_pcb) and make it active. Refuses to overwrite an existing project. template: '2layer' (default) | '4layer' | 'blank' (KiCad defaults, no fab rules). fab: the fab profile whose design rules the project gets (default: the configured one). board_size: [width_mm, height_mm] draws a rectangular outline. dir: the parent folder (the project goes in dir/), or the project folder itself when it ends in ; default Documents/Copper/. KiCad re-loads the files (ERC + DRC) before success is reported. Example: project_create(name='usb-sensor', board_size=[50,30])

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "project_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
dirNoparent folder, or the project folder itself if it ends in <name>
fabNofab profile name (fab_export(profile='list') shows them)
revNo
nameYes
titleNo
companyNo
templateNo
board_sizeNo[width_mm, height_mm]

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations only declare destructiveHint=false and openWorldHint=false; the description adds substantial behavior beyond that, including the three files written, that the project is made active, that overwrite is refused, the default output location, and that KiCad re-loads files with ERC + DRC before success is reported. It does not say what happens when validation fails or whether partial files are left behind, which keeps it from 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?

Front-loaded with the core action and artifacts, then compact per-parameter notes and a closing example, with no filler sentences. The terse 'param: meaning' notation is efficient, though the omitted jlc-* templates make the parameter block slightly misleading rather than merely short.

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?

For a mutation tool with 8 parameters and no output schema, the description covers the important ground: artifacts created, side effects, overwrite protection, defaults, and the ERC/DRC validation step. The remaining gaps (rev/title/company semantics and the incomplete template enumeration) are minor but real for a tool that writes files.

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 only 38% schema description coverage across 8 parameters, the description does real work: it explains template values and their default, what fab controls and where to list profiles, the [width_mm, height_mm] format and its outline effect, and the tricky dir rule (parent folder vs. folder ending in <name>) plus its default. However, it omits rev, title, and company entirely, and its template list ('2layer' | '4layer' | 'blank') does not match the five-value enum, which also contains 'jlc-2layer' and 'jlc-4layer'.

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 plus the concrete artifacts produced (.kicad_pro, .kicad_sch, .kicad_pcb) and the post-condition that the project becomes active. That distinguishes it cleanly from project_open and the rest of the sibling set without needing to inspect the schema.

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?

Gives clear context for use (starting a new project) and an explicit when-not condition: it refuses to overwrite an existing project. It stops short of naming project_open as the alternative for existing projects, so routing is implied rather than stated.

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

Deploy Server

Other Tools