Copper

Overview Schema Source Related Servers Discussions Admin

Copper pour / zones

pcb_pour

Idempotent

Creates copper pour zones for a chosen net and layers, fills them, and reruns DRC; unreachable pads are connected or reported, with optional stitching vias.

Instructions

Copper pour: a zone for one net (default GND) over the whole outline on the chosen layers (default F.Cu + B.Cu), then fill every zone and re-run DRC. Pads the fill cannot reach get a solid connection or a via; what still cannot join is reported with its position. stitch=true adds stitching vias. A pour on an inner layer is a plane. Re-running replaces the net's zone; remove=true deletes it; fill_only=true just refills after moving or routing. Examples: pcb_pour() · pcb_pour(net="GND", stitch=true) · pcb_pour(net="+3V3", layers=["In2.Cu"]) · pcb_pour(fill_only=true)

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_pour"
  }
}

Input Schema

Name	Required	Description
`net`	No	Net to pour (default GND)
`layers`	No	Copper layers (default [F.Cu, B.Cu])
`remove`	No	Remove this net's zones
`render`	No	attach a PNG (default false)
`stitch`	No	Add a grid of stitching vias (only where both layers are filled)
`project`	No	project path (default: active)
`priority`	No
`clearance`	No	Zone clearance mm (default 0.3)
`fill_only`	No	Only refill existing zones
`min_width`	No	Minimum fill width mm (default 0.25)
`while_open`	No	refuse (default) \| revert
`thermal_gap`	No	Thermal relief gap mm (default 0.5)
`stitch_pitch`	No	Stitching via pitch mm (default 5)
`thermal_spoke`	No	Thermal spoke width mm (default 0.5)
`pad_connection`	No	tht_thermal (default: thermal reliefs on through-hole pads, solid SMD pads — reflow friendly, no starved thermals), thermal, solid, none

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Nov 13, 2026

TDQS

A4.1/5.0

Behavior4/5

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

The annotations only say openWorldHint=false, idempotentHint=true, and destructiveHint=false, but the description adds substantive behavior beyond them: the fill reruns DRC, pads that the fill cannot reach get a solid connection or a via, and remaining failures are reported with their position. One mild tension is that 'remove=true deletes it' describes a destructive path even though destructiveHint=false; the delete is opt-in and explicitly disclosed, so this is not a contradiction, but it deserves a small deduction.

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?

It is front-loaded with the core action, followed by mode semantics and compact examples. The first sentence is a slightly overloaded run-on ('...then fill every zone and re-run DRC'), but every sentence carries information.

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 15-parameter mutation/fill tool with no output schema, the description covers side effects, reporting of unreachable pads, idempotent replacement semantics, and the inner-layer 'plane' case. Missing are the meaning of `priority` and the `while_open` refuse/revert trade-off, which is the only reason it falls short of complete.

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 coverage is 93%, so the schema already documents nearly all 15 parameters, including defaults for net, layers, clearance, and stitch_pitch; the description adds little beyond restating the GND/F.Cu+B.Cu defaults and the 'only where both layers are filled' stitch constraint. `priority` has no description in the schema and is not explained in the description either, which is a real gap for a 15-parameter tool.

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 opens with a concrete verb+resource: 'Copper pour: a zone for one net (default GND) over the whole outline on the chosen layers', then specifies the fill and DRC follow-up. No sibling tool does pour work, so the name plus this sentence is enough to tell that it is not pcb_route, pcb_edit, or pcb_setup.

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 clearly explains which mode to use in which situation: 're-running replaces the net's zone', 'remove=true deletes it', and 'fill_only=true just refills after moving or routing'. The four worked examples show common call shapes, though no exclusion against an alternative tool is stated.

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