eda-agent

by Nivakaran-S

Overview Schema Source Related Servers Discussions Admin

Python

Local

lib_search

Search open .SchLib files and installed database libraries to find components by name, description, or parameters.

Instructions

Search open SchLib documents and installed database libraries.

OPEN .SchLib FILES AND INSTALLED DATABASE LIBRARIES (DbLib) ARE SEARCHED. Query libraries (SVN DbLib), integrated libraries (IntLib), workspace components and installed .SchLib files that are not open are not, so 0 hits is not "no such part". The reply says what was searched (libraries_searched, DbLibs included) and lists every installed library it could not read (not_searched, with the reason), with a coverage_note when anything was skipped.

DbLib rows join results after the SchLib matches, with what is left of limit, each marked source: "dblib" and carrying its table, key, symbol and footprints; SchLib matches are marked source: "schlib". Every column of a row is matched, so a manufacturer part number or a value finds the part. A DbLib that cannot be connected stays under not_searched with the reason, and dblib_searches says what each DbLib search covered. Use lib_dblib_search to restrict to one table or a few columns, and lib_dblib_get_record for every column of one row.

Case-insensitive substring match. Walks every .SchLib that is a member of any open project, plus every standalone .SchLib in the workspace's free-documents area. Each library is read via CreateLibCompInfoReader so the search is fast even with many libraries open: it only loads symbols when search_type is "parameters".

IT READS THE FILE ON DISK, NOT THE EDITOR. A component created in this session and not yet saved WILL NOT BE FOUND, and the reply is an ordinary empty result with nothing to say why. MEASURED: a symbol that lib_get_component_details returned in full was absent here until a save. Save first, or use lib_get_component_details / lib_get_pin_list, which read the live document.

DATASHEET DISCIPLINE: Matches carry _datasheet_guidance. Before recommending any matched part as a replacement or answer, fetch its datasheet (WebSearch + WebFetch). Do not recommend based on symbol metadata alone.

Args: query: Substring to match against component name / alias / description (case-insensitive). search_type: "all" (default, matches name / alias / description), "name", "description", or "parameters" (slow, also walks each candidate's parameter dict via the live symbol). library_path: Optional path to a single .SchLib, or to a single .DbLib, to restrict the search to. When omitted, searches every open .SchLib and every installed DbLib. limit: Cap on returned matches (default 100), SchLib and DbLib together. include_dblibs: also search the installed database libraries (default True). Their rows are read through the connection each DbLib declares, every row of every enabled table up to lib_dblib_search's row bound, so a large database makes the search slower; False keeps it to open .SchLib files and lists the DbLibs under not_searched. A library_path naming a .DbLib searches that one either way.

Returns: Dict with query, search_type, count, limit, truncated (True when count == limit, or when a DbLib search stopped early), and results, a list of {name, alias_name, description, library_path, part_count, source} per match (a DbLib row adds table, key_field, symbol_ref, symbol_library, footprints, matched_field, and its name is the row's key), plus _datasheet_guidance + _datasheet_parts; and libraries_searched, not_searched (each {library_path, library_type, reason}), dblib_searches and coverage_note as above. Either list is None when it could not be read.

Input Schema

Name	Required	Default
`limit`	No
`query`	Yes
`search_type`	No	all
`library_path`	No
`include_dblibs`	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.8/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: it discloses that it reads the file on disk rather than the editor, that an unsaved component returns an ordinary empty result with no diagnostic, and cites a measured case. It also discloses performance behavior (DbLib rows read through each declared connection up to lib_dblib_search's row bound, 'a large database makes the search slower') and the coverage-reporting fields libraries_searched / not_searched / coverage_note.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded correctly — scope first, caveats before args — and the ALL-CAPS warnings are well placed. But it runs long, and the 'Returns:' block enumerates every field of the response even though has_output_schema is true, duplicating structured data the agent already receives.

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 5-parameter search tool with zero annotation and zero schema-description coverage, the description covers search universe, negative space, failure modes, cost tradeoffs, and per-parameter meaning. Nothing an agent needs in order to call it correctly, or to interpret a zero-hit 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% across 5 parameters, so the description must compensate and it does: query's match targets, search_type's four literal values including the slow 'parameters' mode, library_path's dual .SchLib/.DbLib meaning, limit as a combined SchLib+DbLib cap defaulting to 100, and include_dblibs' default and cost. This is materially more than the bare titles and defaults in the schema.

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 opening sentence states a specific verb and resource ('Search open SchLib documents and installed database libraries') and the body immediately narrows scope against siblings: 'Use lib_dblib_search to restrict to one table or a few columns, and lib_dblib_get_record for every column of one row.' An agent can distinguish this from lib_get_component_details, lib_dblib_search and lib_get_installed_libraries without opening any 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?

It gives explicit exclusions ('SVN DbLib, integrated libraries (IntLib), workspace components ... are not [searched], so 0 hits is not "no such part"') and explicit alternatives with the condition that selects them ('Save first, or use lib_get_component_details / lib_get_pin_list, which read the live document'). The include_dblibs=False tradeoff and the library_path-to-a-.DbLib edge case are also spelled out.

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

Deploy Server