mcp-server-kicad

Overview Schema Source Related Servers Discussions Admin

connect_pins

Connect two component pins in a KiCad schematic using Manhattan L-shaped wire routing, automatically placing wires and junctions.

Instructions

Connect two component pins with Manhattan (L-shaped) wire routing.

Combines get_pin_positions + coordinate math + add_wires into one call. At its own
points (both pins and the L's corner) a junction goes where three or more directions
meet, and any wire through it is split there, as KiCad's wire tool does
(sch_line_wire_bus_tool.cpp:1263-1267 at 9.0.8); a leg running through a junction or a
bus entry end already on the sheet is split there too, as KiCad's cleanup splits it. The
result names each junction and split.

Args:
    ref1: First component reference (e.g. "U1")
    pin1: First pin name or number
    ref2: Second component reference (e.g. "C3")
    pin2: Second pin name or number
    schematic_path: Path to .kicad_sch file. Optional; omit to use the configured default.

Input Schema

Name	Required	Description	Default
`pin1`	Yes
`pin2`	Yes
`ref1`	Yes
`ref2`	Yes
`schematic_path`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.9.1Jun 10, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations only declare it is a non-readonly, non-idempotent, non-destructive mutation. The description goes well beyond that, disclosing that junctions are created at meeting points, that existing wires are split there (citing KiCad behavior), and that the result names each junction and split. It stops short of stating reversibility or permission requirements.

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 a clear first sentence, but the junction paragraph is dense and cluttered with source-file line citations (sch_line_wire_bus_tool.cpp:1263-1267) that consume space without helping the agent invoke the tool. The Args block is clean and useful.

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?

Output schema exists, so return-value explanation is unnecessary, and the description still notes that junction/split names are produced. For a mutation tool it communicates the key side effects, though it omits whether junction insertion can be suppressed and how failures are reported.

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 description coverage is 0%, so the description must carry the burden, and it largely does: it documents all five args including examples ('U1', 'C3') and the fact that schematic_path is optional with a configured default. It leaves pin name-vs-number format and path format slightly ambiguous, but compensates adequately.

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 (connect), resource (two component pins), and the routing strategy (Manhattan / L-shaped). It also clarifies the tool's abstraction level by saying it bundles get_pin_positions + coordinate math + add_wires, so an agent can distinguish it from the low-level add_wires sibling.

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 'combines X + Y + Z into one call' framing implies when to prefer this over manually chaining the three lower-level tools, which is useful. However, it never names or contrasts with close siblings like wire_pins_to_net or add_wires, and gives no when-not conditions or prerequisites.

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

Deploy Server