eda-agent

Overview Schema Source Related Servers Discussions Admin

lib_dblib_search

Search .DbLib database libraries read-only for components using case-insensitive text across selected tables or columns, with row limits and scan reporting.

Instructions

Search database libraries (.DbLib) for components, read-only.

Case-insensitive substring match against the columns of every row of every enabled table, in one DbLib or in every installed one. lib_search already folds DbLib rows into its own results; this is the direct form, for restricting to one table or a few columns, or for raising the row bound on a large database.

THE QUERY NEVER REACHES THE DATABASE. Each table is read with a plain SELECT of the DbLib's own declared table and every row is matched inside Altium, so a query holding quotes, wildcards or SQL is matched as the text it is. The cost is that every row is read: max_rows bounds the total, rows_scanned reports it, and scan_capped says the bound cut the search short.

Args: query: Text to find (case-insensitive substring). library_path: One .DbLib to search. Omitted, every installed database library is searched. table: One table the DbLib declares (as lib_dblib_info names it). Omitted, every enabled table. fields: Column names to match. Omitted, every column. A name a table lacks is reported under unknown_fields. limit: Cap on returned rows (1 to 1000, default 50). max_rows: Cap on rows read in total (default 20000).

Returns: {"query", "count", "limit", "truncated", "rows_scanned", "scan_capped", "libraries": [{"library_path", "searched", "error", "tables_searched", "tables_failed", "unknown_fields"}], "results": [{"library_path", "table", "key", "key_field", "symbol_ref", "symbol_library", "footprints": [{"ref", "library"}], "description", "matched_field", "matched_value"}]}. A library's error is a code (READ_FAILED, TABLE_UNKNOWN, NO_TABLES, NO_CONNECTION_STRING, CONNECT_FAILED, LIMIT_REACHED); the reason text never carries the connection string.

Input Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes
`table`	No
`fields`	No
`max_rows`	No
`library_path`	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.9/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 so: it discloses that the query never reaches the database (so quotes/wildcards/SQL are literal text), that every row is read so cost scales with table size, that max_rows bounds the scan and scan_capped flags truncation, and that error text never carries the connection string.

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 and the key differentiator, and the sections are well organized. The Returns block is long and largely redundant given that an output schema exists, which is the only reason it falls short of a 5.

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 six-parameter search tool with no annotations, the description covers usage, cost model, failure modes, and error codes. An output schema exists, so the return section is extra rather than needed, and 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%, so the description must compensate, and it does: every one of the six parameters is explained, including the limit range (1–1000, default 50), max_rows default 20000, that fields are column names with unknowns reported under unknown_fields, and that table names must match what lib_dblib_info reports.

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 (search) and resource (database library .DbLib components) with scope (case-insensitive substring across columns of every enabled table). It explicitly distinguishes itself from the sibling lib_search, explaining that lib_search folds DbLib rows into its own results while this is the direct form.

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?

Names the alternative tool (lib_search) and the conditions that select this one instead: restricting to one table or a few columns, or raising the row bound on a large database. It also states defaults for library_path, table, and fields when omitted.

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

Deploy Server