Skip to main content
Glama
ProductOfAmerica

mcp-server-kicad

add_wires

Add multiple wire segments at once to a KiCad schematic, automatically placing junctions and splitting wires at connections while preventing accidental shorts across parts.

Instructions

Add multiple wires at once, as KiCad's wire tool adds them. Each wire dict has keys: x1, y1, x2, y2.

Following SCH_LINE_WIRE_BUS_TOOL::finishSegments (sch_line_wire_bus_tool.cpp:1168-1276 at
9.0.8): a junction goes wherever three or more wire directions, pins or sheet pins meet,
at a new wire's end or at a point already on the sheet that a new wire runs through (a
pin, a wire end), and every wire through a junction is split there, so a T, or a wire
drawn through a pin, joins in every reader. As KiCad merges the new wire with the
collinear wires of its stroke that it overlaps or meets end to end (where no junction
is), a stretch such a wire already covers is left out, and a merged run holding both
pins of a two-pin part loses the stretch between them, so drawing across a part never
shorts it. A wire of no length is left out, as KiCad's tool drops one. Existing wires
are only ever split: where KiCad's trim would cut a wire already on the sheet, the call
is refused and nothing is written. The result counts the wire nodes written and names
each junction, split, left-out and trimmed stretch; when nothing changes it says so and
writes nothing.

Args:
    wires: List of wire defs [{x1, y1, x2, y2}, ...]
    schematic_path: Path to .kicad_sch file. Optional; omit to use the configured default.

Input Schema

NameRequiredDescriptionDefault
wiresYes
schematic_pathNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.11.0
    • addedInput schema / $defs
      Added value: +{
      +  "WireSpec": {
      +    "description": "One wire segment's two endpoints.",
      +    "properties": {
      +      "x1": {
      +        "title": "X1",
      +        "type": "number"
      +      },
      +      "x2": {
      +        "title": "X2",
      +        "type": "number"
      +      },
      +      "y1": {
      +        "title": "Y1",
      +        "type": "number"
      +      },
      +      "y2": {
      +        "title": "Y2",
      +        "type": "number"
      +      }
      +    },
      +    "required": [
      +      "x1",
      +      "y1",
      +      "x2",
      +      "y2"
      +    ],
      +    "title": "WireSpec",
      +    "type": "object"
      +  }
      +}
    • addedInput schema / properties / wires / items / $ref
      Added value: +"#/$defs/WireSpec"
    • removedInput schema / properties / wires / items / additionalProperties
      Removed value: -true
    • removedInput schema / properties / wires / items / type
      Removed value: -"object"
  2. First observedv0.9.1

TDQS

A3.8/5.0
Behavior5/5

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

Far exceeds the annotations: it discloses that junctions are auto-created at 3+ wire directions/pins, that existing wires are only split and the call is refused with nothing written when KiCad's trim would cut an existing wire (atomicity), that zero-length wires are dropped, and that merging across a two-pin part never shorts it. It also states the result reports junctions/splits/left-out/trimmed stretches and that no-op calls write nothing.

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

Conciseness3/5

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

Purpose is front-loaded in the first sentence, but the behavioral paragraph is a dense run-on that includes low-value implementation trivia (source file, line numbers, version 9.0.8). Much of it earns its place, yet it could be cut substantially without losing agent-relevant 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?

An output schema exists, so return values need not be spelled out, yet the description still summarizes what the result counts. Combined with the mutation/refusal semantics it covers the operation well; the main residual gap is coordinate units and the absence of guidance relative to sibling wire tools.

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 0%, so the description must carry the load. It restates the WireSpec keys and usefully clarifies that schematic_path is optional and falls back to the configured default (which the schema's empty-string default does not convey), but it never states coordinate units or origin for x1/y1/x2/y2 — a meaningful gap for a geometry tool.

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 ("Add multiple wires at once") and clarifies it mirrors KiCad's own wire tool, which separates it from PCB-side siblings like add_trace. It does not explicitly distinguish itself from close schematic siblings such as connect_pins, wire_pins_to_net, or add_junctions, leaving some ambiguity for an agent choosing among wire-creation tools.

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?

Usage is implied rather than stated: batch-drawing wire segments on a schematic, with junctions handled automatically (hinting you need not call add_junctions). There is no explicit when-to-use versus when-not, and no named alternative such as connect_pins or wire_pins_to_net despite those being obvious siblings.

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