Skip to main content
Glama

lib_set_label_formats

Batch-apply label styles—font, color, visibility, orientation, and justification—to SchLib designators, comments, or parameters across one component or the whole library in a single pass.

Instructions

Multi-target label-style writer for SchLib symbols.

Applies SEVERAL label target/style ops to SchLib symbols in one IPC round-trip (there is no singular variant). The library is opened once and walked once; every op is applied to each component in turn. Five sequential per-target writes would collapse into one trip plus one library walk -- which is the dominant cost on large libraries (each individual call runs an IPC, a workspace lookup, a doc-focus check and a CompInfoReader walk).

Each op is a dict describing one label target -- no field has a built-in default, only the ones you supply get written:

{"target": "designator",         # required
 "font_id": <int>,               # optional
 "color":   <int>,               # optional, BGR-packed
 "is_hidden": False,             # optional
 "orientation": <int>,           # optional, 0/90/180/270
 "justification": <int>}         # optional

At least one style field must be set per op. Targets are "designator", "comment", or "parameter:<Name>". Use obj_get_font_id / obj_get_font_spec to resolve the font_id for {name, size, bold, italic} from the active library's font table; that keeps the call neutral to any particular library's style choices.

Args: ops: List of per-target style ops. Must be non-empty. Targets may not contain the wire separators ; or ~~. component_name: When set, applies only to that one component. Omit for bulk-walk across the library. library_path: .SchLib path. Defaults to focused doc. only_mismatched: When True (default) skip labels already matching the target style. Applies globally to every op. limit: Cap on processed components in bulk mode. timeout: Per-call bridge poll timeout override.

Returns: Dict with library_path, scope ("single"|"bulk"), total, limit, truncated, and an ops array each with target, modified, already_compliant, missing_target, failed.

Input Schema

NameRequiredDescriptionDefault
opsYes
limitNo
timeoutNo
library_pathNo
component_nameNo
only_mismatchedNo

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 provided, the description carries the behavioral burden well: it discloses the one-IPC batch behavior, single library open/walk, per-component application, no implicit field defaults, required non-empty ops, separator restrictions, global only_mismatched behavior, bulk limit, and return structure.

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 and well structured around purpose, op shape, args, and returns. It is somewhat verbose in the IPC cost explanation and repeats return details despite an output schema being present, but the length is defensible for a complex batch write tool.

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?

The definition is complete enough for an agent to call it correctly: the complex op structure is fully documented, scope behavior for single vs bulk mode is covered, mismatch skipping and limits are explained, and an output schema exists for return values.

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 coverage is 0%, so the description must compensate, and it does: it defines the op object fields, required target, allowed target values, optional style fields, BGR-packed color, orientation values, the at-least-one-style-field rule, plus component_name, library_path, only_mismatched, limit, and timeout semantics.

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?

The description gives a precise verb and resource: a multi-target label-style writer for SchLib symbols. It clearly says several label target/style ops are applied in one call, and notes there is no singular variant, which makes the tool's role distinct.

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?

The description explains the intended bulk scenario and recommends using obj_get_font_id / obj_get_font_spec to resolve font_id. However, it does not explicitly compare this tool with nearby alternatives such as lib_audit_styles or lib_batch_set_params, and it gives no explicit 'do not use when' guidance.

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