kicad

Overview Schema Source Related Servers Discussions Admin

update_component

Modify one or more properties of an existing component in a KiCad schematic. Provide the reference designator and only the properties to change (value, position, rotation, footprint).

Instructions

Update component properties.

Updates one or more properties of an existing component. Only provided parameters will be updated.

Args: reference: Component reference designator to update (e.g., "R1") value: New component value (if provided) position: New position as (x, y) tuple in mm (if provided) rotation: New rotation in degrees (0, 90, 180, or 270) (if provided) footprint: New footprint identifier (if provided) ctx: MCP context for progress reporting (optional)

Returns: ComponentInfoOutput with updated component information, or ErrorOutput on failure

Examples: >>> # Update value only >>> result = await update_component("R1", value="20k")

>>> # Update multiple properties
>>> result = await update_component(
...     "R1",
...     value="20k",
...     footprint="Resistor_SMD:R_0805_2012Metric",
...     rotation=90.0
... )

Input Schema

TableJSON Schema

Name	Required	Description	Default
`value`	No
`position`	No
`rotation`	No
`footprint`	No
`reference`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 6, 2026

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description must carry the behavioral burden. It discloses the partial-update behavior and the return contract (ComponentInfoOutput or ErrorOutput on failure), which is meaningful. However, it omits prerequisites (schematic must be loaded?), whether an unknown reference errors, and whether changes are reversible or persisted to disk.

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 statement of purpose followed by Args, Returns, and Examples. The examples are borderline redundant with the Args list but demonstrate multi-property updates, which has value. Overall tight and well-ordered.

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 5-param mutation tool with no annotations, the description covers parameters, partial-update semantics, and return/error behavior, plus worked examples. An output schema exists so the Returns line is not strictly required. Missing only edge-case behavior for invalid references or missing prerequisites.

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 compensate, and it largely does: it documents each parameter's meaning, units ('position as (x, y) tuple in mm'), the rotation constraint (0/90/180/270), and an example value. It is a raw Args list without type/nullability detail, so slightly short of full compensation.

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 ('Update component properties') and clarifies it targets 'an existing component', which distinguishes it from add_component/remove_component siblings. It does not explicitly name or differentiate against overlapping siblings like manage_components, so it stops short of a 5.

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 line 'Only provided parameters will be updated' is a genuinely useful usage rule (partial update semantics), but there is no explicit when-to-use/when-not-to-use guidance or routing to alternatives such as manage_components or add_component for new components.

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