eda-agent

Overview Schema Source Related Servers Discussions Admin

lib_audit_styles

Audit visual styles across all schematic library components and filter for designators that mismatch expected font or color to find style inconsistencies.

Instructions

Bulk visual-style audit across every component in a library.

Walks the focused .SchLib (or one specified by library_path) component-by-component and emits each component's designator style record. Comment / parameter_styles / pins are opt-in via the with_* flags so the default response stays compact: designator alone is ~120 bytes per component, so a 2000-symbol library is ~240 KB without filters.

Filter mode: pass expect_designator_font_id and/or expect_designator_color and the response only contains components whose designator does NOT match the expected style. That makes the audit case (find every symbol that doesn't use Times New Roman 10pt navy) a single round-trip with bounded output.

timeout overrides the bridge default. A 2000-symbol audit with no opt-in flags finishes well under the 10s default; pass a larger value if you flip on with_parameters and the lib has heavy parameter dicts.

Args: library_path: .SchLib path. Defaults to focused doc. with_comment: Include comment style record per component. with_parameters: Include parameter_styles array per component. with_pins: Include pins array per component. expect_designator_font_id: Filter; trim components where designator.font_id equals this value. expect_designator_color: Filter; trim components where designator.color equals this BGR int (e.g. 8388608 for navy / 0x000080 in BGR-packed form). limit: Cap on emitted entries. Default 5000. timeout: Per-call bridge poll timeout override (seconds).

Returns: Dict with library_path, count (emitted), mismatch_count (subset that failed the filter), limit, truncated, filter_applied, and components: list of {name, designator:{...}, mismatched, comment?:{...}, pins?:[...], parameter_styles?:[...]}.

Input Schema

Name	Required	Description	Default
`limit`	No
`timeout`	No
`with_pins`	No
`library_path`	No
`with_comment`	No
`with_parameters`	No
`expect_designator_color`	No
`expect_designator_font_id`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Oct 29, 2026

TDQS

A4.3/5.0

Behavior4/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 well: it quantifies payload size (~120 bytes/component, ~240 KB for 2000 symbols), discloses the 10s bridge default and timeout override, and explains that filter mode trims output to non-matching components for bounded results. It does not explicitly confirm the operation is read-only or state failure/permission behavior.

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-loads purpose, then filter mode, then Args/Returns, so the important information comes first and each section is scannable. It is long and repeats title-level parameter names in prose that also appear in the schema, but the length is largely justified by 8 undocumented params and no annotations.

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?

Covers invocation scope (focused doc vs library_path), opt-in cost model, filter behavior, timeout tuning, and the full return shape including count, mismatch_count, truncated, filter_applied and per-component fields. For an 8-param, annotation-free tool, nothing an agent needs to call it correctly 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 Args block fully compensates by defining all eight parameters, including the non-obvious BGR int encoding for expect_designator_color (8388608 = navy) and the filter semantics of expect_designator_font_id. This adds meaning well beyond the bare schema types and defaults.

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 ('Bulk visual-style audit across every component in a library') and scopes it to designator style records on a .SchLib, so an agent can tell it apart from single-item tools like lib_probe_designator. It never names a sibling alternative explicitly, which keeps it just shy of a 5.

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 concrete when-to-use context: opt-in flags for comment/parameters/pins keep the default compact, filter mode exists for the 'find every symbol that doesn't match' case, and it advises raising timeout when with_parameters is enabled on heavy libraries. It stops short of stating when NOT to use it or routing to a specific alternative tool.

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

Deploy Server