Skip to main content
Glama
ProductOfAmerica

mcp-server-kicad

place_footprint

Place a footprint on a PCB with pads, silkscreen, and 3D model copied from a KiCad library. Use it to add real components for routing and DRC, or omit library for a pad-less marker.

Instructions

Place a footprint on the PCB.

Name a library and a footprint to place the real thing: its pads, silkscreen,
courtyard and 3D model are copied from the library file exactly as KiCad
would place them, a footprint in KiCad 7's form taking the reference and value
in its own (fp_text reference|value ...), where one holding %V or %R, which KiCad
reads there as a variable, is refused. Without them you get a marker carrying
only the reference and value, which has NO PADS and so cannot be routed or
checked; that is the older behaviour and it is kept for callers that only want a
placeholder.

Use list_lib_footprints to see what a library holds.

The footprint is turned to its rotation as KiCad's own rotate turns it: every
pad and text turns with it (a pad's angle is its library angle plus the
footprint's), and a keep-upright text that would read upside down is turned
half a turn with its justification mirrored, so it stays readable on the same
side of its anchor. Angles are written as KiCad writes them: the footprint's
between -180 and 180 and left out at 0, each pad's and text's absolute. Off the
quarter turns the result reads as KiCad's placement without matching pcbnew's
save byte for byte: footprint-relative coordinates stay as the library writes
them where pcbnew re-derives them through two RotatePoint roundings, an fp_rect
stays where pcbnew writes an fp_poly, and arc mid points stay as written. A
library footprint without a Datasheet or Description field is placed without
it, so KiCad reads that hidden field at its default on F.Fab, whereas pcbnew
writes it, on B.Fab for a placement on the back.

Zones the footprint owns (keepouts, say) and a KiCad 10 footprint's points are
stored in board coordinates (format( ZONE ), pcb_io_kicad_sexpr.cpp:2628-2637 at
9.0.8), so they land where KiCad's placement puts them: moved with the footprint,
turned about it and, on the back, mirrored with it.

A footprint carrying what this tool does not move with it (a dimension, image,
table or barcode, or a child no KiCad it knows reads), or on the back what it does
not flip (see move_footprint), is refused and nothing is written.

Args:
    reference: Reference designator (e.g. "R2")
    value: Component value (e.g. "4.7K")
    x: X position in mm
    y: Y position in mm
    rotation: The footprint's angle in degrees, counter-clockwise as seen on
        screen; any finite value (270 is stored as -90, 360 as 0). inf and nan
        are refused and nothing is written.
    layer: F.Cu or B.Cu; any other layer is refused. B.Cu places the footprint
        flipped as KiCad's own flip does, then turns it to rotation
        (FOOTPRINT::Flip, pcbnew/footprint.cpp:2491-2550 at 9.0.8).
    library: Footprint library nickname (e.g. "Resistor_SMD"), or a path to a
        .pretty directory. A nickname is resolved as update_pcb_from_schematic
        resolves it: the project's fp-lib-table beside the board, .pretty
        directories beside the board, KICAD_FP_LIB, the user's global
        fp-lib-table (with the libraries the Plugin and Content Manager
        installed), then KiCad's stock footprints. Optional; omit for a
        pad-less marker.
    footprint: Footprint name within that library (e.g. "R_0805_2012Metric").
        Required when library is given.
    pcb_path: Path to .kicad_pcb file. Optional; omit to use the configured default.

Input Schema

NameRequiredDescriptionDefault
xYes
yYes
layerNoF.Cu
valueYes
libraryNo
pcb_pathNo
rotationNo
footprintNo
referenceYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.20.1
    • addedInput schema / properties / footprint
      Added value: +{
      +  "default": "",
      +  "title": "Footprint",
      +  "type": "string"
      +}
    • addedInput schema / properties / library
      Added value: +{
      +  "default": "",
      +  "title": "Library",
      +  "type": "string"
      +}
  2. First observedv0.9.1

TDQS

A4.2/5.0
Behavior5/5

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

Annotations are thin (non-readonly, non-destructive, non-idempotent), so the description carries the burden and does so thoroughly: refusal conditions and their atomicity ('nothing is written'), layer flipping via FOOTPRINT::Flip, text variable-refusal on %V/%R, back-layer Datasheet/Description defaults on B.Fab, and zone coordinate handling. This is unusually rich behavioral disclosure, well beyond annotations.

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

Conciseness2/5

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

The purpose sentence is front-loaded, but the middle paragraphs are extremely dense KiCad-internals prose (pcbnew roundings, format() line references, fp_rect vs fp_poly) that a calling agent rarely needs and that pushes the actionable content (refusal conditions, layer/rotation rules) far down.

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

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists and annotations cover mutation flags, the description need not explain return values, and it does cover the critical caller-facing rules. However, for a 9-param tool with 0% schema coverage, more of the earlier prose should have been spent on the parameters themselves and less on internal serialization details.

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 0%, so the description must compensate and largely does: it defines rotation semantics (CCW as seen on screen, 270 stored as -90, inf/nan refused), layer (F.Cu/B.Cu only, B.Cu flips then rotates), library resolution order, and pcb_path default. It does not spell out x/y units beyond 'mm' (which it does state) or fully disambiguate footprint/librar as required pairs beyond the library-implies-footprint rule.

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 (place) and resource (footprint on PCB) and immediately differentiates the two modes: a real library footprint versus a pad-less marker. Siblings move_footprint and remove_footprint operate on existing footprints, and the description makes clear this creates a new one.

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?

Explicitly routes the agent to list_lib_footprints to discover library contents, and clearly states the condition for omitting library/footprint (pad-less placeholder for callers wanting only reference and value). Does not explicitly contrast with place_component or move_footprint, but the create-vs-move distinction is implied.

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