Skip to main content
Glama
ProductOfAmerica

mcp-server-kicad

add_power_symbol

Place VCC, GND, or other power symbols at specified coordinates in a KiCad schematic. Use it during schematic capture to define power nets and connect components to rails.

Instructions

Place a power symbol (VCC, GND, +3V3, etc.).

Uses place_component internally. Power symbols are regular symbols
from the 'power' library with isPower=True.

Places only the symbol asked for. A PWR_FLAG tells ERC the net has a
source it cannot see, which only the designer knows, so add one with
lib_id="power:PWR_FLAG" on each net that needs it.

Args:
    lib_id: Library ID (e.g. "power:VCC", "power:GND")
    reference: Reference (e.g. "#PWR01")
    x: X position
    y: Y position
    rotation: Rotation in degrees
    symbol_lib_path: Path to a .kicad_sym file that defines the power symbol,
        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
lib_idYes
rotationNo
referenceYes
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/5.0
Behavior4/5

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

Annotations already declare non-readOnly, non-destructive, non-idempotent. The description adds real behavioral context beyond that: the internal delegation to place_component, the isPower=True nature of the symbols, and the ERC semantics of PWR_FLAG (tells ERC the net has a source it cannot see). It does not discuss repeat-call behavior despite idempotentHint=false, so not a 5.

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-loads the purpose, then mechanism, then the PWR_FLAG note, then a structured Args block. Every sentence conveys useful information, though the PWR_FLAG paragraph is slightly tangential to the core placement action. Well organized and appropriately sized for an 8-parameter tool.

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?

With an output schema present, return values need not be described. For an 8-parameter placement tool the description covers purpose, mechanism, ERC-related behavior, and every parameter including optional/default semantics. It is essentially complete, missing only explicit sibling routing guidance.

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 delivers a complete Args section explaining all 8 parameters: lib_id with concrete examples, reference format '#PWR01', rotation in degrees, symbol_lib_path for out-of-stock libraries with default behavior, schematic_path default, and project_path purpose. This fully compensates for the empty schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Place a power symbol') with examples (VCC, GND, +3V3), and clarifies the mechanism by noting it uses place_component internally and that these are regular 'power' library symbols with isPower=True, which helps distinguish it from generic symbol placement. It does not explicitly contrast against add_symbol or place_component for the main use case, so differentiation is good but not complete.

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?

Provides domain guidance on the PWR_FLAG companion case and clarifies 'Places only the symbol asked for', but gives no explicit when-to-use-this-vs-siblings rule (e.g., versus place_component or add_symbol). Usage is implied rather than stated, so the minimum-viable 3 fits.

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