Skip to main content
Glama

lib_normalize_implementations

Clean up a SchLib by collapsing duplicate component models, clearing stale provenance, repairing footprint links, and optionally setting source library paths for embeddable footprints.

Instructions

Clean up every component's models in a SchLib for a self-contained package.

Whole-library sweep. Per component it: clears the component-level provenance (SourceLibraryName, TargetFileName); collapses duplicate models, keeping ONE per (model_type, model_name) IN PLACE so the kept model's parameters, MapAsString pin-map, and datafile link are all preserved; re-flags the survivor current if any duplicate was; optionally renames a model's name and its datafile entity via rename_map; and repairs any footprint (PCBLIB) left with no datafile link. It does NOT destroy and rebuild implementations, so nothing on a model is lost.

With source_library set, it also writes that value into the Location of every PCBLIB model's datafile link, turning a name-only library (footprints resolve but do not embed) into an embeddable one in the same pass. Existing Locations are only overwritten when source_library is given; they are never blanked. Get the exact string from a known-good model first (see lib_set_model_source).

Note: it preserves what is present; it cannot resurrect data a prior broken run already dropped. If a library was damaged by an earlier version, restore the backup and run this on it.

If you are also renaming footprint entities, run lib_rename_footprint on the PcbLib first, then pass the same {old: new} as rename_map so symbol and footprint stay matched.

Args: library_path: optional .SchLib path; defaults to the focused lib. rename_map: optional {old_model_name: new_model_name} applied to the kept model's name and matching datafile entity. dedupe_only: skip renames; only collapse duplicates + clear source. source_library: optional; when set, written into every PCBLIB model's datafile Location so footprints embed on compile. use_component_library: optional; sets the embed-vs-search flag on the models whose Location is written.

Returns: {"success": true, "components_touched": N, "duplicates_removed": N, "sources_cleared": N, "links_repaired": N, "sources_set": N}.

Input Schema

NameRequiredDescriptionDefault
rename_mapNo
dedupe_onlyNo
library_pathNo
source_libraryNo
use_component_libraryNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.6/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: it explains that duplicates are collapsed in place preserving parameters, pin-map and datafile link, that existing Locations are never blanked, that damage from a prior broken run cannot be undone (restore backup first), and that the operation is non-destructive. These are exactly the side-effect and irreversibility facts an agent needs before mutating a library.

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 with the core action and scope, then behavior, caveats, and args in a logical order. It is long and has mild repetition (the non-destructive point is made twice), but nearly every sentence carries operational weight.

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 destructive-capable, five-parameter library mutation with no annotations, the description supplies ordering prerequisites, irreversibility warnings, and per-parameter meaning. An output schema exists, so the included Returns block is a bonus rather than a necessity.

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 coverage is 0%, but the Args block explains all five parameters semantically: library_path defaulting to the focused lib, rename_map's {old: new} shape and that it applies to both model name and datafile entity, dedupe_only's effect, source_library's write target, and use_component_library's embed-vs-search role. Types are left to the schema, but the meaning gap is closed.

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 ('clean up every component's models in a SchLib') plus the goal (self-contained package) and the whole-library scope. It distinguishes itself from model-level siblings like lib_set_model_source and lib_rename_footprint by describing the batch sweep rather than a single edit.

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?

Gives clear when-to-use context: set source_library to convert a name-only library into an embeddable one, use dedupe_only when renames aren't wanted, and run lib_rename_footprint on the PcbLib first when renaming footprint entities. It points at lib_set_model_source for obtaining the exact Location string, though it doesn't explicitly contrast against other cleanup siblings.

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