Skip to main content
Glama
Sign In
Copper

Copper

by claynicholson
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Board outline, holes, rules

pcb_setup
Idempotent

Configure a KiCad board's outline, mounting holes, copper layers, fab design rules, net classes, and silkscreen text; only supplied settings are changed.

Instructions

Board setup: outline, corner mounting holes, copper layer count, fab design rules + net classes, silkscreen text size. Only what you pass is changed. Outline, one of: width x height mm rectangle (optional radius; REPLACES the existing outline), polygon, auto_size=true (smallest comfortable rectangle for the parts, unrouted boards only), or outline_file='case.step' (STEP, DXF, SVG, STL; 'auto' = the one file in mechanical/): the board body or an enclosure's cavity with its arcs, cutouts and mounting holes; an uncertain pick lists candidates (outline_pick), outline_dry_run=true only analyses. First setup applies the design rules of the project's fab profile (rules='fab'). power_nets adds nets / patterns to the Power net class. Examples: pcb_setup(width=40, height=30) · pcb_setup(width=50, height=50, radius=2, holes='M3', layers=4) · pcb_setup(outline_file='mechanical/case.step', outline_dry_run=true) · pcb_setup(power_nets=['VBAT','SW'], power_track=0.8)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

NameRequiredDescriptionDefault
viaNoDefault via [diameter, drill] mm
holesNoCorner mounting holes
rulesNoDesign-rule preset: fab | <fab profile>[_advanced] | jlc | jlc_advanced | relaxed | none (default on first setup: the project's fab profile)
widthNoBoard width mm
heightNoBoard height mm
layersNoCopper layers
originNoTop-left corner [x,y] mm (default [100,100])
radiusNoCorner radius mm (0 = square)
renderNoattach a PNG (default false)
polygonNoCustom outline [[x,y],...] instead of width/height
projectNoproject path (default: active)
hole_netNoUse plated holes tied to this net (e.g. GND)
auto_sizeNoPick the board size from the parts (no tracks/zones/locked parts)
silk_textNoReference designator height mm (most fabs print ≥ 0.8; default 1.0)
hole_insetNoHole centre distance from the board edges mm (default 3.5)
power_netsNoExtra Power-class nets / wildcard patterns, e.g. ['VBAT','BATN','SW','*_PWR']
while_openNorefuse (default) | revert
power_trackNoPower net class track width mm (keeps the project's value if omitted)
outline_axisNoWhich way is up (component side / enclosure opening)
outline_fileNoCAD file for the outline (.step .stp .stpz .dxf .svg .stl) or 'auto'
outline_flipNoMirror left-right (drawn from the solder side)
outline_modeNoboard = file is the PCB; enclosure = fit into its cavity; face = use outline_pick
outline_pickNoCandidate id from an earlier result's candidates[]
default_trackNoDefault net class track width mm (keeps the project's value if omitted)
outline_holesNomounting (default): 1.8-6.6 mm circles become mounting holes; all: every inner contour is cut
outline_layerNoDXF layer / SVG group id or label holding the outline
outline_unitsNoUnits for STL / unit-less DXF, SVG
outline_dry_runNoAnalyse and show the pick, write nothing
outline_clearanceNoInward offset mm (default 0; 0.5 for an enclosure)
outline_keep_positionNoKeep the file's coordinates instead of moving to origin

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the idempotent/non-destructive annotations it discloses real behavior: partial mutation ('Only what you pass is changed'), that a rectangle outline 'REPLACES the existing outline', that an ambiguous file pick returns candidates for outline_pick, that 'auto' means the single file in mechanical/, and that dry-run writes nothing. These are exactly the operational facts an agent needs before mutating a board.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Despite its length it is densely packed with zero filler: purpose first, then the outline decision tree, then the rule/power-net behavior, then worked examples. Each clause conveys an actionable constraint rather than restating the name.

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 30-parameter mutation tool with no output schema, the description covers the risky and ambiguous parts (outline sourcing, replacement semantics, dry-run, candidate picking, rule defaults) well. It does not touch some behavioral knobs such as while_open or render, but those are fully described in the schema.

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?

Schema coverage is 100% so the baseline is 3, but the description earns more by explaining relationships the schema cannot: the exclusivity of the outline input modes, the meaning of outline_file='auto', the first-setup fabrication-rule default, and how power_nets feeds the Power net class. It leaves a number of secondary parameters (via, origin, render, silk_text, while_open, outline_layer/units/axis/flip) entirely to the schema.

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?

The description names a specific verb and resource (board setup) and enumerates the exact concerns it configures: outline, corner mounting holes, copper layer count, fab design rules and net classes, silkscreen text size. That enumeration separates it cleanly from siblings like pcb_edit, pcb_place, and pcb_route without needing their schemas.

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 spells out the mutually exclusive ways to supply an outline (width/height rectangle with optional radius, polygon, auto_size, or outline_file) and the preconditions for each, e.g. auto_size is 'unrouted boards only' and outline_dry_run analyses without writing. It also states the first-setup rule-preset default and gives four concrete call examples, though it does not contrast against sibling tools such as pcb_edit or board_build.

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