Skip to main content
Glama

lib_get_components

Retrieve all components from an EasyEDA Pro library with names, aliases, descriptions, and optional parameters or default designators for library audits.

Instructions

Get all components in a library.

Default fast path returns only the metadata that the ILibCompInfoReader exposes directly: name, alias_name, part_count, description. That path scales linearly with file IO and finishes in well under a second on typical libraries.

Setting with_parameters=True adds each component's full parameter dict (Manufacturer, Value, Footprint, etc.) to the result. That branch calls GetState_SchComponentByLibRef once per symbol and iterates parameters, which is O(N) in the live SchLib document and is what makes the call slow on libraries with many hundreds of components. Use it when you need the parameters; for a single symbol's parameters, prefer lib_get_component_details.

Setting with_designator=True adds each component's DEFAULT designator (Component.Designator.Text, e.g. "U?" / "R?" / "IC?"). The CompInfoReader fast path does NOT expose the designator, so this also loads each live symbol (same cost driver as with_parameters) but skips parameter iteration, keeping the payload small. Intended for library-wide designator-consistency audits.

Args: library_path: Path to library (uses active library if not specified) with_parameters: If True, include each component's parameter dict (slow on large libraries). Default False. with_designator: If True, include each component's default designator string (slow on large libraries; smaller payload than with_parameters). Default False.

part_count HERE IS NOT TRUSTWORTHY. It comes from the CompInfoReader, and MEASURED on AD26 it reported 2 for a symbol created single-part whose every pin carries OwnerPartId 1, while lib_get_component_details reported 1 for an identically created symbol. The two readers disagree and only the discrepancy is established, not a conversion between them, so no correction is applied here rather than guess one. Use lib_get_component_details when the part count matters.

Returns: Dictionary with count and components list. Each component carries index, name, alias_name, part_count, description, (only when with_parameters is True) parameters, and (only when with_designator is True) designator.

``index`` is a stable addressing key (position in library
order). Pass it as ``component_index`` to lib_get_component_details
/ lib_delete_component / lib_rename_component to reach a
component whose ``name`` contains bytes you cannot reproduce
(an embedded double-quote, or a control char from a broken
import), the case where matching by name fails.

Input Schema

NameRequiredDescriptionDefault
library_pathNo
with_designatorNo
with_parametersNo

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 exist, so the description carries the full burden and does: it discloses that the fast path is IO-bound and sub-second, that with_parameters/with_designator load each live symbol and are O(N) in the SchLib document, and that with_designator yields a smaller payload. It also flags that part_count is unreliable with the concrete measured discrepancy behind the claim.

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 cost/benefit framing is front-loaded and each paragraph corresponds to one flag, so the structure is easy to scan. It is longer than strictly necessary, though, and the part_count caveat spends several clauses on AD26 measurement detail before reaching the actionable instruction.

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 the three flags, their performance trade-offs, the return shape, and the stable index addressing key used by lib_get_component_details/lib_delete_component/lib_rename_component, including the case where name-matching fails. Nothing an agent needs to call this correctly is missing, even though an output schema also exists.

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: library_path falls back to the active library, with_parameters adds the parameter dict (slow), with_designator adds only the default designator string (also slow but cheaper). It goes further by warning that part_count is untrustworthy and must not be read as the details-tool count.

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 ('Get all components in a library') and immediately differentiates itself from lib_get_component_details for single-symbol and part-count use cases. An agent can pick between the two 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?

Explicit routing: default fast path for metadata only, with_parameters 'use it when you need the parameters' but prefer lib_get_component_details for a single symbol, with_designator for 'library-wide designator-consistency audits', and lib_get_component_details when part count matters. When-to-use, when-not, and named alternatives are all present.

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