Skip to main content
Glama

Set design rules

set_design_rules

Set the project design rules (.kicad_pro) and copper layer count. Works on a board workspace and on a generated design (create_design → start_board). On a generated design the rules go into circuit.kicad_pro/.kicad_dru in place (the previous ones are snapshotted under rules_revisions/), are kept by every later project write (project.zip, a new board run), the copper is not changed and KiCad DRC judges the board against them at once: the reply carries the DRC counts and whether the Gerbers are released; the next start_board routes to the default_* values. copper_layers, stackup and board_thickness_mm are workspace-only (a generated design changes them with a new board). preset "jlcpcb" applies JLCPCB's published minimums for the layer count and writes their per-feature limits (plated rings, pad hole spacing, hole-to-track) as KiCad custom rules (.kicad_dru) that run_drc checks; explicit values override the minimums. Board minimums (min_*), the Default net class (default_*), and named net classes with their net patterns. route_board routes with these rules and run_drc checks against them. Changing copper_layers rebuilds the stackup; tracks on removed layers are reported. copper_layers 1 is a single-sided board (hand etching): the KiCad file keeps F.Cu and B.Cu, and from then on the routers hold to one face (B.Cu as soon as a THT pad exists, else F.Cu) and place no via; copper on the other face is removed.

Input Schema

NameRequiredDescriptionDefault
presetNo
wait_sNoSeconds to wait for the job (default 55). A job still running comes back with status "running": follow it with get_board_job. A job is allowed the time its budget asks for (time_budget_s, total_budget_s, rounds), and survives a server restart (the op starts over from its snapshot; route_board's pipeline goes on from its last finished stage).
stackupNo1.6 mm impedance stackups, written into the board: JLCPCB's 4-layer 7628 (0.21 mm prepreg, their default) or 3313 (0.1 mm prepreg: thinner pairs for the same impedance), and 6- / 8-layer 3313 builds (approximations of the fab's, from its 3313 outer prepreg and human 1.6 mm boards). Needed before a net class states diff_impedance_ohm.
design_idYesThe design id returned by import_kicad_project or list_designs.
net_classesNo
min_track_mmNo
copper_layersNo
hole_to_hole_mmNo
default_track_mmNo
min_clearance_mmNo
hole_clearance_mmNo
board_thickness_mmNoFinished board thickness; the stackup is rebuilt to it. JLCPCB FR4: 0.4, 0.6, 0.8, 1.0, 1.2, 1.6, 2.0 mm.
min_via_annular_mmNo
min_via_diameter_mmNo
default_clearance_mmNo
default_via_drill_mmNo
min_through_drill_mmNo
default_via_diameter_mmNo
copper_edge_clearance_mmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / stackup / description
      Previous value: -"JLCPCB's 4-layer 1.6 mm impedance stackups, written into the board: 7628 (0.21 mm prepreg, their default) or 3313 (0.1 mm prepreg: thinner pairs for the same impedance). Needed before a net class states diff_impedance_ohm."New value: +"1.6 mm impedance stackups, written into the board: JLCPCB's 4-layer 7628 (0.21 mm prepreg, their default) or 3313 (0.1 mm prepreg: thinner pairs for the same impedance), and 6- / 8-layer 3313 builds (approximations of the fab's, from its 3313 outer prepreg and human 1.6 mm boards). Needed before a net class states diff_impedance_ohm."
    • changedInput schema / properties / stackup / enum
      Previous value: -[
      -  "JLC04161H-7628",
      -  "JLC04161H-3313"
      -]New value: +[
      +  "JLC04161H-7628",
      +  "JLC04161H-3313",
      +  "KOPPAR-6L-1.6-3313",
      +  "KOPPAR-8L-1.6-3313"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / wait_s / description
      Previous value: -"Seconds to wait for the job (default 55). A job still running comes back with status \"running\": follow it with get_board_job. A job is allowed the time its budget asks for (time_budget_s, total_budget_s, rounds), and survives a server restart (the op starts over from its snapshot)."New value: +"Seconds to wait for the job (default 55). A job still running comes back with status \"running\": follow it with get_board_job. A job is allowed the time its budget asks for (time_budget_s, total_budget_s, rounds), and survives a server restart (the op starts over from its snapshot; route_board's pipeline goes on from its last finished stage)."
  3. Changed1 schema field changed
    • changedInput schema / properties / wait_s / description
      Previous value: -"Seconds to wait for the job (default 55). A job still running comes back with status \"running\": follow it with get_board_job."New value: +"Seconds to wait for the job (default 55). A job still running comes back with status \"running\": follow it with get_board_job. A job is allowed the time its budget asks for (time_budget_s, total_budget_s, rounds), and survives a server restart (the op starts over from its snapshot)."
  4. First observed

TDQS

A3.5/5.0
Behavior1/5

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

The description discloses many behavioral consequences, including snapshots under rules_revisions/, persistence across later project writes, DRC evaluation, and routing effects. However, it also states that copper on the other face is removed when copper_layers is 1, which contradicts destructiveHint=false; that is a real destructive side effect despite the annotation.

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?

The purpose is front-loaded and the length is largely justified by a complex 19-parameter mutation tool. The text is a dense run-on paragraph with some repeated DRC discussion, so it could be structured more cleanly, but there is little outright filler.

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 complex tool with no output schema, the description covers the two execution contexts, persistence, snapshots, DRC consequences, preset behavior, and the reply content. It is not fully complete because several parameters remain semantically thin, but the major operational context is present.

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 only 21% across 19 parameters, so the description must compensate. It does explain preset, copper_layers, stackup, board_thickness_mm, net_classes, and grouping for min_* and default_* parameters, but it leaves hole_to_hole_mm, hole_clearance_mm, copper_edge_clearance_mm, and several individual minimum/default fields to their names alone.

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 first sentence states a specific verb and resource: setting project design rules (.kicad_pro) and copper layer count. It also distinguishes the two operational contexts, board workspace versus generated design, so the agent can tell what this tool does without opening 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?

The description clearly explains when the tool applies to a board workspace versus a generated design, how the jlcpcb preset behaves, that explicit values override preset minimums, and which parameters are workspace-only. It does not explicitly route the agent away from overlapping tools such as set_keepouts or set_zones, so it stops short of full alternative guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources