Skip to main content
Glama
Sign In
datasheet-lens

datasheet-lens

by turbyho
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

part_parameters

Lists filter parameters and example values for a component category at DigiKey or JLCPCB, so you can choose valid filters before searching parts.

Instructions

The parameters of a part category at a source of the parametric search (DigiKey, or the JLCPCB parts library), for the filters of find_parts: the full name, the short name, the number of parts with a value, the number of values and examples of the values (jlcpcb: of the parts with JLCPCB stock). The parameters that most parts have come first: a parameter of few parts can be a parameter of a different part type in the same category. Use it before find_parts.

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": "part_parameters"
  }
}

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.
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.
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".

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A3.8/5.0
Behavior4/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 more than most: it discloses the return fields (full name, short name, count of parts with a value, count of values, examples), the ordering rule ('parameters that most parts have come first'), and why that ordering matters (a sparse parameter may belong to a different part type in the same category). It also flags the JLCPCB-specific caveat that examples reflect parts with JLCPCB stock. It never states read-only/no-side-effect behavior, which is the main gap.

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?

The definition is one long run-on sentence with stacked parentheticals ('(jlcpcb: of the parts with JLCPCB stock)') and an embedded caveat after a colon, which makes it harder to scan. The key usage instruction lands last rather than being front-loaded. Content is mostly worthwhile, but the packaging is clumsy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not explain return values, yet it still names the fields an agent will see. Combined with the source and category parameters, an agent has enough to call it correctly. Only the missing read-only/error-behavior statement keeps it from being fully complete for a no-annotation tool.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents path, source, and category in detail. The description reinforces the meaning of 'source' and frames the parameters as filters for find_parts, but adds no format or syntax guidance beyond the schema. Baseline 3 applies.

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?

The description names the specific resource ('the parameters of a part category at a source of the parametric search') and the sources it covers (DigiKey, JLCPCB), and ties it to the sibling tool find_parts. It is clear it is a metadata/introspection tool rather than a search, though the opening sentence is dense and requires careful reading.

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?

It gives an explicit sequencing instruction: 'Use it before find_parts.' That tells the agent where this tool sits in the workflow. It does not discuss alternatives such as jlcpcb_library, search_distributors, or distributor_status, so routing among non-find_parts siblings is left to inference.

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