Skip to main content
Glama

lib_fix_designators

Aligns every footprint's designator to the library's own convention for layer, height and pad-centred position, planning changes first as a dry run and applying them iteratively until converged.

Instructions

Bring every footprint's .Designator onto the library's OWN convention: the layer, height and centring the majority already use.

Nothing is hard-coded. The target layer, its raw ordinal, the norm height and the centring tolerance are all inferred from this library (see lib_audit_footprint_policies); policy overrides any of them. "Centred" means on the AVERAGE PAD CENTRE, not the library origin.

DEFAULTS TO A DRY RUN. With dry_run=True (the default) it reports exactly which footprints it would touch, on which layer, and at which coordinates, and writes nothing. Pass dry_run=False to apply.

Applying RUNS TO CONVERGENCE: apply, save, reload the PcbLib, re-plan, repeat until nothing is left. The reload is mandatory, not cosmetic: Altium caches each text's bounding rectangle at load and never refreshes it when the text moves or is resized, so a second pass without a reload would centre against stale geometry and shove designators off the part. Resizing a text also changes its box, so height fixes and centring settle over successive passes rather than one.

PARTIAL SUCCESS IS EXPECTED AND REPORTED, NOT HIDDEN. A small number of designators (a handful per library) do not persist a position change through Altium's save for reasons not yet diagnosed: the write reads back changed but the value reverts on reload. Rather than loop forever or claim success, the tool stops when a pass makes no progress and returns converged: false with the offending footprints in unrepairable for a human to centre by hand. Everything else is applied. applied counts only writes confirmed by read-back, never attempts.

Args: library_path: .PcbLib to fix; defaults to the focused library. dry_run: report the plan without writing (default True). fix_layer: move designators off the convention layer onto it. fix_center: re-centre designators beyond the library's tolerance. fix_height: also normalise text height to the library norm. add_missing: create a .Designator on footprints that lack one. policy: explicit conventions, e.g. {"designator_center_tol": 50, "designator_height": 20}.

Returns {library_path, dry_run, conventions, planned, applied, created, passes, converged, failed, skipped, actions}.

Input Schema

NameRequiredDescriptionDefault
policyNo
dry_runNo
fix_layerNo
fix_centerNo
fix_heightNo
add_missingNo
library_pathNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.7/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 burden and does so thoroughly: dry-run default, mandatory reloads due to Altium text-bound caching, convergence looping, expected partial failures, `unrepairable` reporting, and `applied` counting only read-back-confirmed writes. This is unusually rich behavioral disclosure.

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 purpose, then behavior, then arguments and returns. It is long, but most detail is justified by the tool's convergence and partial-failure behavior, though some prose 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?

For a seven-parameter mutation tool with no annotations, it covers purpose, operational modes, convergence behavior, failure handling, parameter meanings, and return fields. The output schema exists, but the description's return summary is still useful and complete.

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%, but the description fully compensates with an Args section documenting all seven parameters, including defaults, the focused-library default for `library_path`, and a concrete `policy` example. It adds substantial meaning beyond the bare schema.

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: bring every footprint's `.Designator` onto the library's own convention for layer, height, and centring. It also defines 'centred' precisely as average pad centre, distinguishing this from generic origin-based centring.

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?

Clearly explains the default dry-run workflow and how to apply changes with `dry_run=False`, which is strong operational guidance. It references `lib_audit_footprint_policies` for inferred conventions but does not explicitly compare this tool against other designator-related siblings such as conversion or rotation audits.

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