kicad

Overview Schema Source Related Servers Discussions Admin

add_label

Add a net label to a KiCad schematic to name nets and connect wires that are not physically joined. Set text, position, rotation, and size.

Instructions

Add a net label to the schematic.

Net labels are used to name electrical nets and establish connections between non-physically connected wires with the same label name.

Args: text: Label text (net name) position: Label position as (x, y) tuple in mm rotation: Label rotation in degrees (0, 90, 180, 270), defaults to 0 size: Text size in mm, defaults to 1.27 (KiCAD standard) ctx: MCP context for progress reporting (optional)

Returns: Dictionary with success status and label information

Examples: >>> # Add VCC label >>> result = await add_label( ... text="VCC", ... position=(100.0, 100.0) ... )

>>> # Add label with rotation
>>> result = await add_label(
...     text="GND",
...     position=(150.0, 100.0),
...     rotation=90.0
... )

Input Schema

TableJSON Schema

Name	Required	Description	Default
`size`	No
`text`	Yes
`position`	Yes
`rotation`	No

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

A3.6/5.0

Behavior2/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 mentions a return value and shows examples, but does not state prerequisites (e.g., a loaded schematic), mutation side effects, whether changes require saving, or any constraints on duplicate labels. This is a significant gap for a write operation.

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?

The description is front-loaded with a clear purpose sentence, then structured into Args, Returns, and Examples. It is slightly long but every section adds value; the examples are helpful and not excessive.

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?

Given that there are no annotations, an output schema exists, and four parameters have 0% schema coverage, the description is nearly complete: it documents all parameters, indicates return format, and provides usage examples. It falls short only on sibling routing and prerequisites, which would make it fully self-contained.

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 must compensate. It documents every parameter with meaning, units, defaults, and allowed values: text as label net name, position as (x,y) in mm, rotation in degrees with allowed 0/90/180/270, and size in mm with the KiCAD standard default of 1.27. This is exactly what an agent needs.

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?

The description states a clear verb ('Add') and resource ('net label to the schematic') and explains what net labels are used for. It does not, however, distinguish this tool from siblings like add_bus_label, manage_labels, or manage_global_labels, so sibling differentiation is absent.

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 description explains the conceptual purpose of net labels ('name electrical nets and establish connections between non-physically connected wires'), which implies when to use one. But it gives no explicit when-to-use guidance or alternatives (e.g., when to use a global label instead), leaving the agent to infer.

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