Skip to main content
Glama

lib_set_pad_properties

Modify existing PcbLib footprint pads by setting copper size, shape, rotation, hole, plating, paste and mask expansions; only supplied fields change and results are read back.

Instructions

Change pads that already exist in a PcbLib footprint.

Every pad named pad_name in the footprint is changed, and only the fields you pass are written, so setting plating leaves the shape alone. Each pad is read back afterwards and the reply reports what it holds, not what was asked.

A mask or paste expansion is written with the pad's manual flag set: without it Altium ignores the value and follows the board's rule, and a library has no rules. hole_width makes the hole a slot; hole_rotation is relative to the pad, so a slot lines up when its long axis matches the copper's in the pad's frame (see slot_aligned in lib_get_pad_geometry). On a pad with a per-layer stack only the top size is written, and note says so.

THE MASK HAS TWO SIDES. A pad keeps a top and a bottom solder mask expansion; with the sides linked the top value serves both, but the bottom value is still stored and takes effect the moment the sides are unlinked. So mask_expansion writes both sides unless mask_bottom_expansion is given too, which writes the bottom and unlinks the sides. mask_separate links or unlinks them explicitly. The reply reads back all three.

Args: footprint_name: The footprint holding the pad. pad_name: The pad's designator. library_path: Optional .PcbLib path; defaults to the focused library. units: "mil" (default) or "mm", for every length here. x_size, y_size: Copper size. shape: "round", "rectangular" or "octagonal". rotation: Pad rotation in degrees. hole_size: Hole diameter, 0 for a surface-mount pad. hole_width: Slot length; makes the hole a slot. hole_rotation: Slot rotation relative to the pad, in degrees. plated: Whether the hole is plated. paste_expansion, mask_expansion: Expansions, set as manual. mask_expansion is the top side, and the bottom too unless mask_bottom_expansion is given. mask_bottom_expansion: The bottom side's mask expansion; the sides are unlinked. mask_separate: Link (False) or unlink (True) the two sides.

Returns: pads_changed, pads_with_a_failed_write, note and pads, each as read back (position, size, rotation, hole, slot, plating, expansion states, mask_expansion_mm, mask_bottom_expansion_mm, mask_separate, all_writes_ran).

Input Schema

NameRequiredDescriptionDefault
shapeNo
unitsNomil
platedNo
x_sizeNo
y_sizeNo
pad_nameYes
rotationNo
hole_sizeNo
hole_widthNo
library_pathNo
hole_rotationNo
mask_separateNo
footprint_nameYes
mask_expansionNo
paste_expansionNo
mask_bottom_expansionNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so extensively: partial writes, read-back semantics, manual mask flags, slot creation, relative slot rotation, per-layer stack behavior, and the linked/unlinked mask-side interaction are all disclosed.

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 long but justified by the tool's complexity. It is front-loaded with the core action and structured with Args/Returns, though the mask-side explanation is somewhat dense and could be tightened.

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?

Given 16 parameters, zero schema description coverage, and no annotations, the description is remarkably complete. It covers behavior, parameter semantics, and even return values, so an agent has everything needed to call the tool correctly despite the output schema's existence.

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%, yet the description explains every parameter beyond its name: units default, hole_size=0 for SMD, hole_width slot semantics, hole_rotation relative to the pad, mask_expansion writing both sides unless mask_bottom_expansion is given, and mask_separate link/unlink meaning. This fully compensates for the empty schema descriptions.

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: 'Change pads that already exist in a PcbLib footprint.' The phrase 'already exist' distinguishes it from pad-adding siblings, but it does not explicitly contrast with other pad-editing tools such as pcb_set_pad_properties or lib_add_footprint_pad.

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 clear context for use: editing existing pads in a library footprint, with only passed fields written. It lacks explicit when-not guidance or named alternatives, so an agent must infer that this is for library footprints rather than board-level pad edits.

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

Deploy Server

Other Tools