Skip to main content
Glama

find_parts

Search DigiKey or JLCPCB for new or replacement parts by parameter filters, returning stock, price, distributor info, and datasheet links to select a component.

Instructions

Find new parts or replacement parts by their parameters (a parametric search) at DigiKey (official API) or in the JLCPCB parts library (a local database for the JLCPCB assembly). Call part_parameters first to get the names and values of the parameters. Gives each filter with its status, and for each part: MPN, manufacturer, distributor number, state or library class, stock, price, the filtered parameters, datasheet and product URL. A numeric filter compares the first number of a value ("2.5V, 8V" gives 2.5 V). A distributor keeps one or few values of a parameter at its own conditions: read each value that the design needs in the datasheet (get_page_image) and save it with save_fact. When the user selects a candidate: adopt_part(source, number) adds its datasheet, the part and its purchase source (not add_document and project_add_part: they save no purchase source). When the source is not available, the error gives the steps for the user: give them to the user.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "source": "<source>",
      "category": "<category>"
    },
    "name": "find_parts"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNoA folder of the user project (default: the working folder of the server). The project file datasheet-lens.toml is in it or in a parent folder.
sortNostock (most first) or price (lowest first).stock
limitNoThe number of parts, 1 to 50 (jlcpcb: 1 to 100).
offsetNoSkip this number of parts (the next page).
sourceYesThe source of the search: digikey (stock and lifecycle state at DigiKey) or jlcpcb (the JLCPCB parts library: JLCPCB stock for the assembly and library class Basic, Preferred or Extended; it applies a condition such as "rds_on <= 10 mOhm at Vgs<=2.5V" to the points that the data lists). distributor_status tells which source is available.
filtersNoThe filters, each "NAME OP VALUE". OP: = < <= > >= has. NAME: a parameter of part_parameters (full name, short name or a unique part of the name; a part of the name that fits more parameters gives the candidates, and the search does not run). = and has accept more values with | (one of them). Examples: "vdss >= 20 V", "channel = N-Channel", "package has 3x3|3.3x3.3", "drive <= 2.5V" (the short names differ for each source: part_parameters gives them; drive is a name of DigiKey only). A condition after "at" ("rds_on <= 10 mOhm at Vgs<=2.5V"): DigiKey does not apply it; jlcpcb applies it to the points that the data lists. Read that value in the datasheet.
categoryYesThe category at the source: its name or a part of its name, for example "mosfet". A text that fits more categories gives the list to select from, with the names in quotes. DigiKey: also its ID. JLCPCB: a subcategory name or "CATEGORY > SUBCATEGORY", more with |, for example "MOSFET|MOSFETs".
in_stockNoTrue: only parts with stock (jlcpcb: with JLCPCB stock for the assembly). False: also the parts with no stock (jlcpcb: marked NOT IN STOCK; digikey: stock 0).
keywordsNoWords that the parts must have. Usually empty.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full burden and does substantial work: it discloses that results include per-filter status, enumerates the returned part fields, describes the numeric-comparison rule ('2.5V, 8V' gives 2.5 V), and explains error behavior plus the datasheet verification workflow (get_page_image, save_fact). It never states that the operation is read-only/no-side-effect or mentions rate limits or auth, which is the remaining gap for an API-backed tool.

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 prerequisite, and every sentence carries operational information rather than restating the name. It is dense and grammatically terse with several long compound sentences, and the adopt_part/error-handling material at the end drifts beyond the find operation, but nothing is truly redundant.

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 9-parameter, dual-backend search tool with no annotations, the description covers the prerequisite, the source choice, filter syntax, result shape, error path, and next step after selection. An output schema exists so return values need no further explanation, and all required parameters are documented.

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 already 100%, yet the description still adds real meaning beyond it: the filter grammar and operator set, the '|' multi-value convention, the 'at' condition semantics differing by source, the ambiguity rule ('a part of the name that fits more parameters gives the candidates, and the search does not run'), and category-matching behavior. This is more than the schema's per-field text conveys.

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?

Opens with a specific verb and resource ('Find new parts or replacement parts by their parameters') and names the two backends (DigiKey official API vs JLCPCB local library), which is the key disambiguation. It does not directly contrast itself with the sibling list_parts or jlcpcb_library, so the boundary is implied rather than stated.

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?

Explicitly prescribes the prerequisite ('Call part_parameters first to get the names and values of the parameters'), names the follow-up tool for the actual selection ('adopt_part(source, number)'), and explicitly excludes the wrong siblings ('not add_document and project_add_part: they save no purchase source'). It also tells the agent what to do on failure ('when the source is not available... give them to the user').

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