mcp-server-kicad

Overview Schema Source Related Servers Discussions Admin

get_pin_positions

Read-onlyIdempotent

Retrieve absolute pin positions for a placed component in a KiCad schematic, accounting for rotation/mirroring and listing every unit of multi-unit symbols.

Instructions

Get absolute pin positions for a placed component (accounts for rotation/mirror).

A multi-unit part is placed as one symbol per unit and they all share the
reference, so every placed unit is listed, each with its own pins plus the
unit-0 pins they all share.

Args:
    reference: Component reference (e.g. "U1", "R1")
    schematic_path: Path to .kicad_sch file. Optional; omit to use the configured default.

Input Schema

Name	Required	Description	Default
`reference`	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 already declare this a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: a multi-unit part is placed as one symbol per unit sharing a reference, and each placed unit is returned with its own pins plus the shared unit-0 pins.

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

Conciseness5/5

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

The core purpose is front-loaded in the first sentence, and the multi-unit explanation is one focused paragraph that earns its space by describing a real return-structure quirk. The Args block is compact and free of filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/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 formatting need not be restated, yet the description still covers the one structural subtlety an agent would otherwise get wrong (per-unit vs shared unit-0 pins). Combined with the optional-parameter behavior, an agent has everything needed to invoke it correctly.

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 load. It documents both parameters: reference with concrete examples ("U1", "R1") and schematic_path as optional with the default-resolution behavior when omitted, which meaningfully compensates for the empty schema.

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+resource ('Get absolute pin positions for a placed component') and immediately narrows scope with the rotation/mirror qualifier, which separates it from library-level tools like get_symbol_pins and get_footprint_pads. It never names a sibling explicitly, so the differentiation is inferable rather than stated.

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 by 'placed component' and it clarifies the optional schematic_path behavior (omit to use the configured default). However, it gives no when-to-use/when-not guidance and never points to alternatives such as get_symbol_pins for library pins or get_footprint_pads for PCB pads.

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

Deploy Server