Skip to main content
Glama

part_search

Search all enabled part providers and merge results, separating library geometry from catalogue identity so you can find parts, datasheets, stock, and know which hits can be drawn.

Instructions

Search EVERY enabled part provider and merge the results.

No provider is a default and none is preferred: all are queried equally, hits carry the provider that found them, and the merged order is alphabetical by provider then part. That ordering is NOT relevance, so do not read the first hit as the best one.

Each provider reports its own status. A provider that cannot answer says why (endpoint withdrawn, software missing) instead of returning nothing, because "unavailable" and "no such part" are different answers and only one means stop looking.

Call with an empty query to list the providers and what they are, including who operates them.

TWO KINDS OF SOURCE, merged but never conflated. A library provider yields GEOMETRY: a symbol or footprint you can place. A catalogue provider (the distributors and aggregators) yields IDENTITY: the manufacturer part number, the datasheet, what is in stock, and NO geometry at all. Every hit carries its kind, because finding out that a distributor hit has no symbol after choosing the part is the expensive way to learn it.

The two answer different questions rather than ranking against each other: a catalogue tells you WHICH part to use and hands you the datasheet every check here measures against, and a library tells you whether you can draw it.

NOTE on maturity="offline": in this catalog that means "needs no Altium", which is true here. It does NOT mean "needs nothing": the remote providers want the internet. With no network the search still succeeds on whatever local providers are enabled (kicad_local reads libraries already on disk) and reports the remote ones as unavailable, so a degraded answer is still a useful one.

DATASHEET DISCIPLINE: a hit is a lead, not a verified part. The provenance and license fields say what the provider claims about where its geometry came from, and a blank means unknown, not permissive. Audit any imported footprint against the manufacturer land pattern with lib_audit_footprint_vs_datasheet before trusting it.

Args: query: substring matched against part name, manufacturer and keywords. Empty lists the providers instead. limit_per_provider: cap per source, so one large registry cannot crowd out the others.

Returns: {"ok", "count", "providers": {name: status}, "hits": [...], "by_mpn": [...]} or, for an empty query, {"ok", "providers": [...]}.

``by_mpn`` correlates the same part across sources, so you
can see which providers carry it and what each states about
provenance and license. Cosmetic spelling differences fold
together; WILDCARD part numbers do not, because KiCad's
``...C8Tx`` is a family placeholder rather than a spelling
of ``...C8T6``, and merging them would assert an equivalence
that is not safe to assume.

Input Schema

NameRequiredDescriptionDefault
queryNo
limit_per_providerNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.2/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 the merge/ordering policy, per-provider status reporting ("unavailable" vs "no such part"), the offline/network failure mode, and the by_mpn correlation rule including why wildcard part numbers are deliberately not folded. These are non-obvious behaviors that an agent could not infer from the schema.

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?

Front-loaded with the essential semantics, but the length is disproportionate for a two-parameter search. The library-vs-catalogue distinction is restated in the paragraph beginning "The two answer different questions," and the datasheet-discipline paragraph overlaps with the catalogue description, so a few sentences do not fully earn their place.

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 everything needed to call and interpret it: query semantics, provider status semantics, result ordering caveats, degraded-network behavior, and the by_mpn correlation. The Returns section additionally explains what by_mpn means beyond the raw output schema, which is more than the schema alone would convey.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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 largely does: query is a substring matched against part name, manufacturer, and keywords, with the empty-string special case spelled out; limit_per_provider is a per-source cap whose rationale (one large registry crowding out others) is given. The numeric default lives only in the schema, which is acceptable.

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 with clear scope: search every enabled part provider and merge results, with no provider preferred. The distinction between library (geometry) and catalogue (identity) sources further clarifies what the tool returns. It doesn't name sibling search tools like lib_search or lib_dblib_search as alternatives, so the differentiation is by scope rather than by explicit contrast.

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?

Explicitly says to call with an empty query to enumerate providers, warns that alphabetical order is not relevance and not to treat the first hit as best, and directs the agent to lib_audit_footprint_vs_datasheet before trusting an imported footprint. It also explains the degraded offline behavior. It stops short of naming competing search tools to route away from.

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