kicad

Overview Schema Source Related Servers Discussions Admin

add_junction

Adds a wire junction at a specified position to indicate T-connections where three or more wires meet, required in KiCAD schematics when a wire branches into multiple paths.

Instructions

Add a wire junction at the specified position.

Junctions indicate T-connections where three or more wires meet. They are required in KiCAD when a wire branches into multiple paths.

Args: position: Junction position as (x, y) tuple in mm diameter: Junction diameter in mm (0 = use KiCAD default) ctx: MCP context for progress reporting (optional)

Returns: Dictionary with success status and junction information

Examples: >>> # Add junction at T-connection >>> result = await add_junction( ... position=(100.0, 100.0) ... )

>>> # Add junction with custom diameter
>>> result = await add_junction(
...     position=(150.0, 100.0),
...     diameter=0.8
... )

Input Schema

TableJSON Schema

Name	Required	Description	Default
`diameter`	No
`position`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 6, 2026

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It usefully discloses the diameter=0 default behavior and that a success-status dictionary is returned, but says nothing about whether the operation fails on duplicate junctions, whether it is idempotent, or what permissions/context are required.

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 with the core action, then structured Args/Returns/Examples. The two examples are concrete and earn their place, though the Args and Returns sections partially duplicate the schema and output schema.

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?

For a two-parameter mutation tool with an output schema available, the description supplies purpose, parameter units/defaults, and return shape. It is largely complete, with the main gap being error/edge-case behavior, which the absent annotations do not cover.

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 it largely does: position is documented as an (x, y) tuple in mm, diameter as mm with 0 meaning KiCAD default, and ctx as an optional MCP context. Units and the default sentinel add meaning the bare schema lacks.

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 and resource ('Add a wire junction at the specified position') and explains what a junction represents ('T-connections where three or more wires meet'), which conceptually distinguishes it from siblings like add_wire and connect_components.

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?

Provides a real usage condition — 'required in KiCAD when a wire branches into multiple paths' — which tells the agent when a junction is needed. It does not, however, explicitly contrast with alternatives such as add_wire or connect_components, which would be needed for a 5.

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