Skip to main content
Glama

lib_set_mech_layers

Set, name, and enable mechanical layers in a specific library by path, with read-back verification to prevent edits from landing on the wrong library.

Instructions

Name, enable and kind the mechanical layers of one library.

WHY THIS EXISTS RATHER THAN THE pcb_* LAYER TOOLS. Those act on whichever board is current, and pointing them at a particular library depends on the focus actually moving. When it does not they operate on the previously focused library while reporting success: a sweep over twenty one libraries returned twenty one identical answers because every call had re-read the same file.

This takes the library by PATH and refuses unless the document that ended up focused is the one asked for. Acting on the wrong library is worse than not acting, because it looks like it worked.

Every change is READ BACK. A layer whose name, enable or kind did not take is reported against that layer rather than folded into an overall pass.

PAIRED KINDS. Any kind ending in Top or Bottom is held by the layer PAIR rather than by either layer, under a shorter name with the side dropped, so "Courtyard Top" is stored as the pair kind "Courtyard". Assigning one therefore needs BOTH sides in the same call: give the partner kind to another layer in layers and the two are joined and the pair given the kind. Single kinds such as "Fab Notes" need no partner.

Pair with lib_run_across to apply the same layer scheme to many libraries in a single call.

Args: layers: One dict per layer. Keys: layer (required, e.g. "Mechanical13"), and any of name, enabled (bool), kind (e.g. "Courtyard Top"). A layer with none of the three is reported as nothing asked for. library_path: The library to edit. Defaults to the focused document, which is only safe for a single library. tidy_pairs: Remove layer pairs no kind justifies. Altium never drops a pair when a kind moves to other layers, so a library reworked more than once accumulates pairs the Layer Stack Manager still shows. A pair survives the tidy only when its two layers carry kinds that are each other's opposite side. Off by default, because it REMOVES pairs and a caller renaming one layer should not have the stack rearranged underneath. timeout: Seconds.

Returns: Dict with library, layers (each: layer, changed, problem), changed, failed, kinds_displaced, pairs_removed, pairs_tidied and pairs_scanned_to.

Input Schema

NameRequiredDescriptionDefault
layersYes
timeoutNo
tidy_pairsNo
library_pathNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.9/5.0
Behavior5/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 and does: it refuses unless the focused document matches the requested path, every change is read back and failures are reported per-layer rather than folded into a pass, and tidy_pairs is flagged as REMOVING pairs with a stated default-off rationale. This is unusually rich behavioral disclosure for a mutation tool.

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 purpose, then rationale, pair semantics, args and returns in a scannable order. It runs long and the 'sweep over twenty one libraries' anecdote could be compressed to a clause, but nearly every sentence carries operational information rather than filler.

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 four-parameter mutation tool with an undocumented schema and no annotations, the definition covers the hard parts: the PAIRED KINDS rule (both sides must appear in the same call), the verification contract, and the return shape. Nothing an agent needs to call it safely and interpret the result is missing.

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% and the layers array is an untyped object bag, so the description must compensate -- and it does, enumerating the required 'layer' key plus optional name/enabled/kind, giving an example ('Mechanical13', 'Courtyard Top'), and explaining that a layer with none of the three is reported as nothing asked for. tidy_pairs, library_path and timeout all receive behavioral meaning beyond their bare types.

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?

Opens with a specific verb triad plus resource and scope: 'Name, enable and kind the mechanical layers of one library.' It then explicitly distinguishes itself from the pcb_* layer tools (pcb_set_mech_layers, pcb_set_mech_layer_kind) that act on the current board, so an agent can route correctly without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States when to prefer this over the pcb_* alternatives and why (focus may not move, causing silent wrong-library edits). It also names the escalation path -- 'Pair with lib_run_across to apply the same layer scheme to many libraries' -- and warns that omitting library_path is 'only safe for a single library.' Explicit when/when-not/alternative coverage.

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