Skip to main content
Glama
ProductOfAmerica

mcp-server-kicad

by ProductOfAmerica
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

auto_place_decoupling_cap

Place a decoupling capacitor in a KiCad schematic and automatically wire its power and ground pins to specified nets using stub wires and labels.

Instructions

Place a decoupling capacitor and wire it to power/ground nets.

Places the cap, wires pin 1 (top) to power_net and pin 2 (bottom)
to ground_net via stub wires + labels.

Args:
    lib_id: Cap symbol (e.g. "Device:C")
    reference: Reference (e.g. "C5")
    value: Cap value (e.g. "100nF")
    x: X position
    y: Y position
    power_net: Label for pin 1 (e.g. "VCC", "+3V3")
    ground_net: Label for pin 2 (e.g. "GND", "PGND")
    rotation: Rotation in degrees (default 0)
    symbol_lib_path: Path to a .kicad_sym file that defines the capacitor,
        for a library outside KiCad's stock set. Optional; omit to load it
        from the stock library named by the lib_id prefix.
    schematic_path: Path to .kicad_sch file. Optional; omit to use the configured default.
    project_path: Path to .kicad_pro file (for sub-sheet instance tracking)

Input Schema

NameRequiredDescriptionDefault
xYes
yYes
valueYes
lib_idYes
rotationNo
power_netYes
referenceYes
ground_netYes
project_pathNo
schematic_pathNo
symbol_lib_pathNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.17.1
    • addedInput schema / properties / rotation / enum
      Added value: +[
+  0,
+  90,
+  180,
+  270
+]
    • changedInput schema / properties / rotation / type
      Previous value: -"number"New value: +"integer"
  2. First observedv0.9.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare non-readOnly, non-idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the exact side effects created (stub wires plus net labels), the pin-to-net mapping, and the default-resolution behavior of the optional path args (omit to use the stock library named by the lib_id prefix, omit to use the configured default schematic).

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 summary followed by a mechanics sentence and an Args block; the ordering is sensible and every line is informative. The opening line and the second sentence overlap slightly (both say it places the cap and wires it), which is minor redundancy but not waste.

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?

An output schema exists so return values need no explanation, and all 11 parameters are covered, including the tricky optional-path semantics. Remaining gaps are the lack of alternative-tool routing and any warning that the operation is non-idempotent (re-running would create duplicate symbols/wires).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden, and it does: every one of the 11 parameters is documented with a concrete example (lib_id "Device:C", reference "C5", value "100nF", power_net "VCC"/"+3V3", ground_net "GND"/"PGND") plus stated defaults and the semantics of the three optional path arguments.

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 compound action (place a decoupling cap AND wire it to power/ground nets) with concrete mechanics — pin 1 to power_net, pin 2 to ground_net via stub wires and labels. This clearly distinguishes it from the generic siblings place_component, add_symbol, connect_pins, and wire_pins_to_net.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The mechanics imply when this tool is preferable (a one-shot decoupling-cap placement) but it never says so explicitly and never names an alternative path such as place_component + connect_pins. No when-not guidance, no prerequisites (e.g. schematic must exist), so the routing decision is left to inference.

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