IC datasheet search: parametric part finding, spec lookup, price comparison — grounded in real PDFs.
Scored across 7 tools
Each tool maps to a distinct retrieval mode (parametric search, ranking comparison, corpus search, segment expansion, image fetching, canonical specs), but lookup/search/get_segments overlap somewhat in scope. The descriptions mitigate this by directing when to prefer lookup vs search.
Most tools follow a clear snake_case verb_noun structure (find_parts, compare_parts, get_image, get_segments, get_specs), with lookup and search as shorter imperative verbs. This is readable and predictable, though not perfectly uniform.
Seven tools cover the datasheet workflow without redundancy: search, lookup, specs, images, compare, and parametric find. The count is appropriate for a focused IC datasheet domain.
The tool set covers the full retrieval workflow from unknown-part corpus search to known-part spec lookup, segmented content, and figure images. Parametric search and part comparison add high-level selection capabilities, with explicit fallback guidance preventing dead ends.
Relative price tier, stock posture, and library class for a set of IC part numbers (a ranking from a distributor snapshot, not a live quote).
| Name | Required | Description | Default |
|---|---|---|---|
| parts | Yes | Two or more IC part numbers to rank relatively; needs >=2 priced parts for a verdict. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does disclose the key trait: the result is a relative ranking based on a distributor snapshot, not a live quote. This manages expectations about freshness and absolute accuracy. It does not discuss auth or errors, but for a read-only comparison tool the main caveat is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence delivers the output dimensions first and the important caveat in a parenthetical. There is no filler or repeated schema content; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with a full output schema, the description covers what is compared, what dimensions are returned, and the snapshot/live-quote caveat. It does not explicitly guide selection among siblings like find_parts or get_specs, but the input contract is fully specified in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains that parts must be two or more IC part numbers with at least two priced for a verdict. The description only restates the concept of a set and adds no syntactic or formatting value, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the input resource (a set of IC part numbers) and the outputs (relative price tier, stock posture, library class), making the tool's function recognizable. It lacks an explicit verb and does not differentiate from siblings like get_specs or lookup, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from a distributor snapshot, not a live quote' gives useful context and an implied exclusion, and the schema adds the requirement of at least two priced parts. However, no alternative sibling tools are named and there is no explicit when-to-use statement, so usage guidance is mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shortlist IC part numbers by parametric spec constraints, ranked by how many constraints each part satisfies, then by headroom past those thresholds, and spread across device families. Each constraint is {canonical, op: gte|lte|eq|range, value, unit?}. Returns per-constraint pass/fail/unknown, plus matched (parts that qualified) vs returned (parts in this response) — when they differ this is a ranked page, not the full set. canonical MUST be one of the exact names below (case-sensitive):
abs_max_current, abs_max_voltage, adc_resolution, block_erase_time, breakdown_voltage_ds, channel_count, clamping_voltage, clock_frequency, cmrr, cmti, coil_power, coil_resistance, coil_voltage, collector_emitter_voltage, contact_current, contact_resistance, core_size, cpu_speed, current_rating, dark_current, data_rate, data_retention, dc_resistance, drain_current, driver_count, dropout_voltage, dynamic_range, eeprom_size, emitter_base_voltage, fall_time, forward_current, forward_voltage, gain_bandwidth, gate_charge, impedance, input_bias_current, input_capacitance, input_offset_current, input_offset_current_drift, input_offset_voltage, input_offset_voltage_drift, input_voltage_noise_density, insertion_loss, io_count, isolation_voltage, junction_capacitance, load_capacitance, memory_size, operate_time, operating_frequency, operating_temperature, output_capacitance, output_count, output_current, output_noise_voltage, output_power, output_voltage, output_voltage_high, output_voltage_low, page_program_time, peak_pulse_current, power_dissipation, program_erase_cycles, program_memory_size, propagation_delay, psrr, quiescent_current, ram_size, rds_on, receiver_count, rectified_current, release_time, response_time, reverse_leakage_current, reverse_recovery_time, reverse_transfer_capacitance, reverse_voltage, rise_time, sample_rate, sector_erase_time, sensitivity, settling_time, slew_rate, standby_current, supply_voltage_range, switching_frequency, switching_voltage, vgs_threshold, zener_voltage
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | Maximum number of parts to return, best first. | |
| constraints | Yes | Spec constraints; a part is ranked by how many it satisfies. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it is very transparent: it explains ranking by constraint satisfaction and headroom, the matched vs. returned distinction, per-constraint pass/fail/unknown output, and the case-sensitive canonical-name requirement. It also notes that `unit` is informational only, which prevents a common misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The prose is tight and front-loaded, with key behavioral details packed into the first two sentences. The long canonical-name list is redundant with the schema's enum but is presented as a direct requirement, so it is justified; still, it makes the description bulkier than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a complex constraint model, the description covers the essential semantics: input shape, canonical names, operator set, ranking behavior, paging nuance, and output semantics. The presence of an output schema means return-value documentation is not required from the description, and nothing critical for calling the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameter details at 100% coverage, so the baseline is 3. The description adds some behavioral context around constraints (ranking, headroom, matched vs. returned) but does not materially add new meaning to the parameters themselves beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Shortlist IC part numbers by parametric spec constraints') and a distinctive resource, making the tool's purpose obvious. It does not explicitly name sibling tools or contrast itself with search/lookup, but the parametric-constraint phrasing is enough to separate it from generic search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening sentence gives a clear context for use: when you need to shortlist IC parts based on parametric constraints. However, it does not state when not to use this tool or explicitly point to alternatives such as search, get_specs, or compare_parts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch datasheet figure images (PNG/JPEG) for opaque ref tokens obtained
from search/lookup/get_segments. Returns each image plus its caption/description/page
metadata. Only type='image' segments have image data; a ref that is not one comes
back as an error record whose available_images lists the document's figures nearest
that ref's page and section, closest first.
| Name | Required | Description | Default |
|---|---|---|---|
| refs | Yes | Opaque `ref` tokens (from search/lookup/get_segments) of image segments; non-image segments return an error record. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It states what is returned (image plus caption/description/page metadata), explicitly warns that non-image refs produce an error record, and explains the fallback behavior with `available_images` and closest-first ordering. This is rich edge-case disclosure for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the core action and then pack in return metadata, the image-segment constraint, and error behavior without fluff. Every clause earns its place, and the structure is easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema and no annotations, this description is unusually complete: it covers input provenance, valid input type, return contents, and invalid-input behavior. There is no missing information that an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents that `refs` are opaque tokens from search/lookup/get_segments of image segments and that non-image segments return an error record. The description largely restates this, adding no meaningful parameter-level meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Fetch datasheet figure images (PNG/JPEG)' for opaque `ref` tokens. It clearly distinguishes this from siblings by scoping it to image segments and by naming the source tools (search/lookup/get_segments) rather than describing general segment retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states that refs must come from search/lookup/get_segments and that only `type='image'` segments have image data, giving an explicit when-to-use boundary. It does not name an alternative tool for non-image segments, but the error behavior makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Expand opaque ref tokens (from search/lookup) into full datasheet segment
content.
| Name | Required | Description | Default |
|---|---|---|---|
| refs | Yes | Opaque `ref` tokens from search/lookup hit records, to expand into full segment content. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of explaining behavior. It conveys the expansion/resolution behavior and the source of the refs, but does not explicitly state non-mutation, behavior on invalid refs, ordering, or other operational traits. The 'expand' wording implies a read-type operation, but explicit safety/error details are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loads the core operation ('Expand'), and provides the essential provenance of the input tokens. Every phrase earns its place, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter, a fully documented schema, and an output schema present, the description covers the core contract well. It could additionally specify edge cases like invalid ref tokens or batch size limits, but for a straightforward expansion endpoint the current level of detail is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a 100% descriptive description for the only parameter, refs. The tool description essentially repeats the same concept without adding new detail about format, limits, or examples, so it adds no meaningful semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb, 'Expand,' and a specific resource: opaque ref tokens from search/lookup into full datasheet segment content. This clearly differentiates the tool from siblings like get_specs or get_image by tying it directly to expanding search/lookup outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description strongly implies the usage context: call this when you have opaque ref tokens produced by search/lookup and need the underlying segment content. It does not explicitly enumerate alternatives or exclusion cases, but the context is clear enough for an agent to select this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read canonical extracted specs (min/typ/max, unit, conditions) for known
IC part numbers from a pre-extracted parametric index — not from datasheet text.
This is the cheapest and most precise source for numeric parameters where it has
coverage. Optionally restrict to specific canonical parameter names.
A part absent from results (with a "No specs found" warning) means no index
coverage, not that the datasheet lacks the parameter — fall back to lookup
for that part.
| Name | Required | Description | Default |
|---|---|---|---|
| canonicals | No | Optional: restrict to these canonical parameter names; omit to return all available specs. | |
| part_numbers | Yes | Exact IC part numbers / MPNs, e.g. ['NE5532', 'LM358']. Family fallback is applied (e.g. TL084CDT -> TL084C). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does so thoroughly: it discloses that results come from a pre-extracted index, that absence of a part in `results` means no index coverage rather than absence in the datasheet, and that the tool issues a 'No specs found' warning. It also clarifies it does not read datasheet text, which is a key behavioral limitation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each serving a distinct purpose: what it reads, when to prefer it, how to restrict output, and what absence means with fallback. The 'cheapest and most precise' phrasing is mildly promotional, but the overall structure is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no annotations, and an output schema, the description covers all essential context: data source, content shape, cost/precision trait, optional filtering, missing-coverage semantics, and fallback routing. An agent has enough to correctly invoke it and interpret an empty result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does reinforce meaning by calling out 'canonical parameter names' and 'known IC part numbers,' but it mostly restates what the schema already explains (optional restriction, exact MPNs). It adds no new syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and resource ('canonical extracted specs ... from a pre-extracted parametric index'), which is clearly distinct from the datasheet-text source and from siblings like lookup. It also defines the spec contents (min/typ/max, unit, conditions), giving the agent a precise mental model of the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'This is the cheapest and most precise source for numeric parameters where it has coverage,' and explicit when-not-to-use by saying it is 'not from datasheet text.' It names the fallback alternative directly: 'fall back to `lookup` for that part,' so the agent is told exactly what to do when coverage is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-shot spec/section retrieval: full content of the most relevant datasheet
segments for one or more parts (fuses search+get_segments). Already groups results per
part (via parts), so prefer lookup over search when you know the part(s).
| Name | Required | Description | Default |
|---|---|---|---|
| parts | No | Part numbers to scope and group the retrieval by; results are returned per part. | |
| query | Yes | What to retrieve, e.g. 'supply voltage' or 'absolute maximum ratings'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that this is a combined one-shot operation, returns full content of relevant segments, and groups results per part. It does not discuss side effects or permissions, but for a retrieval tool the disclosed behavior is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences: the first defines what the tool does, and the second gives routing guidance. No wasted words, and the most important scoping detail is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters, full schema coverage, an output schema, and the description clarifies its relationship to key siblings. An agent has enough information to invoke it correctly and understand its grouping behavior without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema beyond reinforcing the grouping behavior tied to parts, which the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise action: one-shot retrieval of full datasheet segment content for one or more parts. It also differentiates itself from siblings by noting it fuses search and get_segments and groups results per part.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises preferring lookup over search when the part(s) are known, giving a clear usage condition relative to a sibling. It does not enumerate exclusions or alternative comparisons for all siblings, but the guidance is actionable and specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the datasheet corpus; returns hit records (metadata + snippet, each
with an opaque ref). Pass a ref list to get_segments for full content.
If you already know the part number(s), prefer lookup — it fuses this search
with get_segments in one call and groups full content per part. Use search
when the part is unknown, or to triage snippets before pulling full content.
For part-specific queries, pass scope='device:' (e.g. scope='device:NE5532')
to restrict hits to that part and avoid cross-part contamination.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Maximum number of hit records to return. | |
| q | Yes | Free-text query, e.g. 'input voltage noise density'. | |
| scope | No | Optional filter, e.g. 'device:NE5532', to restrict hits to one part and avoid cross-part matches. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the return shape (hit records with metadata, snippet, opaque ref), the opaque-ref indirection to get_segments, and scope-restriction behavior. It does not mention ordering/pagination/errors, but for a search tool the core behavior is well conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and every sentence earns its place: what it returns, how to chain to get_segments, when to prefer lookup, when to use search, and how to scope. The key purpose and return shape are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return-value details beyond the hit-record/ref/segments flow. It covers purpose, return nature, alternatives, usage conditions, and parameter scoping. An agent has enough context to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining why scope should be used (restrict hits to one part and avoid cross-part contamination) and by giving a concrete syntax example. It does not add much about q or k, but they are already well described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Search the datasheet corpus; returns hit records (metadata + snippet, each with an opaque `ref`)." It clearly states what the tool produces and differentiates it from siblings like lookup and get_segments by describing the hit-record/snippet level of detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit routing guidance: prefer lookup when part numbers are known, use search when the part is unknown or for triage before pulling full content. It also explains exactly when to use the scope parameter with a concrete MPN example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
getget_image1 field changedInput schema / properties / refs / descriptionPrevious value: -"Opaque `ref` tokens (from search/lookup/get) of image segments; non-image segments return an error record."New value: +"Opaque `ref` tokens (from search/lookup/get_segments) of image segments; non-image segments return an error record."get_segmentsfind_parts1 field changedInput schema / $defs / Constraint / properties / canonical / enumPrevious value: -[
- "abs_max_current",
- "abs_max_voltage",
- "adc_resolution",
- "block_erase_time",
- "breakdown_voltage_ds",
- "channel_count",
- "clamping_voltage",
- "clock_frequency",
- "cmrr",
- "cmti",
- "coil_power",
- "coil_resistance",
- "coil_voltage",
- "collector_emitter_voltage",
- "contact_current",
- "contact_resistance",
- "core_size",
- "cpu_speed",
- "current_rating",
- "dark_current",
- "data_rate",
- "data_retention",
- "dc_resistance",
- "drain_current",
- "driver_count",
- "dropout_voltage",
- "dynamic_range",
- "eeprom_size",
- "emitter_base_voltage",
- "fall_time",
- "forward_current",
- "forward_voltage",
- "gain_bandwidth",
- "gate_charge",
- "impedance",
- "input_bias_current",
- "input_capacitance",
- "input_offset_current",
- "input_offset_current_drift",
- "input_offset_voltage",
- "input_offset_voltage_drift",
- "input_voltage_noise_density",
- "insertion_loss",
- "io_count",
- "isolation_voltage",
- "junction_capacitance",
- "load_capacitance",
- "memory_size",
- "operate_time",
- "operating_frequency",
- "operating_temperature",
- "output_capacitance",
- "output_count",
- "output_current",
- "output_noise_voltage",
- "output_power",
- "output_voltage",
- "output_voltage_high",
- "output_voltage_low",
- "page_program_time",
- "peak_pulse_current",
- "power_dissipation",
- "program_erase_cycles",
- "program_memory_size",
- "propagation_delay",
- "psrr",
- "quiescent_current",
- "ram_size",
- "rds_on",
- "receiver_count",
- "rectified_current",
- "release_time",
- "response_time",
- "reverse_leakage_current",
- "reverse_recovery_time",
- "reverse_transfer_capacitance",
- "reverse_voltage",
- "rise_time",
- "sample_rate",
- "sensitivity",
- "settling_time",
- "slew_rate",
- "standby_current",
- "supply_voltage_range",
- "switching_frequency",
- "switching_voltage",
- "vgs_threshold",
- "zener_voltage"
-]New value: +[
+ "abs_max_current",
+ "abs_max_voltage",
+ "adc_resolution",
+ "block_erase_time",
+ "breakdown_voltage_ds",
+ "channel_count",
+ "clamping_voltage",
+ "clock_frequency",
+ "cmrr",
+ "cmti",
+ "coil_power",
+ "coil_resistance",
+ "coil_voltage",
+ "collector_emitter_voltage",
+ "contact_current",
+ "contact_resistance",
+ "core_size",
+ "cpu_speed",
+ "current_rating",
+ "dark_current",
+ "data_rate",
+ "data_retention",
+ "dc_resistance",
+ "drain_current",
+ "driver_count",
+ "dropout_voltage",
+ "dynamic_range",
+ "eeprom_size",
+ "emitter_base_voltage",
+ "fall_time",
+ "forward_current",
+ "forward_voltage",
+ "gain_bandwidth",
+ "gate_charge",
+ "impedance",
+ "input_bias_current",
+ "input_capacitance",
+ "input_offset_current",
+ "input_offset_current_drift",
+ "input_offset_voltage",
+ "input_offset_voltage_drift",
+ "input_voltage_noise_density",
+ "insertion_loss",
+ "io_count",
+ "isolation_voltage",
+ "junction_capacitance",
+ "load_capacitance",
+ "memory_size",
+ "operate_time",
+ "operating_frequency",
+ "operating_temperature",
+ "output_capacitance",
+ "output_count",
+ "output_current",
+ "output_noise_voltage",
+ "output_power",
+ "output_voltage",
+ "output_voltage_high",
+ "output_voltage_low",
+ "page_program_time",
+ "peak_pulse_current",
+ "power_dissipation",
+ "program_erase_cycles",
+ "program_memory_size",
+ "propagation_delay",
+ "psrr",
+ "quiescent_current",
+ "ram_size",
+ "rds_on",
+ "receiver_count",
+ "rectified_current",
+ "release_time",
+ "response_time",
+ "reverse_leakage_current",
+ "reverse_recovery_time",
+ "reverse_transfer_capacitance",
+ "reverse_voltage",
+ "rise_time",
+ "sample_rate",
+ "sector_erase_time",
+ "sensitivity",
+ "settling_time",
+ "slew_rate",
+ "standby_current",
+ "supply_voltage_range",
+ "switching_frequency",
+ "switching_voltage",
+ "vgs_threshold",
+ "zener_voltage"
+]find_parts1 field changedInput schema / $defs / Constraint / properties / canonical / enumAdded value: +[
+ "abs_max_current",
+ "abs_max_voltage",
+ "adc_resolution",
+ "block_erase_time",
+ "breakdown_voltage_ds",
+ "channel_count",
+ "clamping_voltage",
+ "clock_frequency",
+ "cmrr",
+ "cmti",
+ "coil_power",
+ "coil_resistance",
+ "coil_voltage",
+ "collector_emitter_voltage",
+ "contact_current",
+ "contact_resistance",
+ "core_size",
+ "cpu_speed",
+ "current_rating",
+ "dark_current",
+ "data_rate",
+ "data_retention",
+ "dc_resistance",
+ "drain_current",
+ "driver_count",
+ "dropout_voltage",
+ "dynamic_range",
+ "eeprom_size",
+ "emitter_base_voltage",
+ "fall_time",
+ "forward_current",
+ "forward_voltage",
+ "gain_bandwidth",
+ "gate_charge",
+ "impedance",
+ "input_bias_current",
+ "input_capacitance",
+ "input_offset_current",
+ "input_offset_current_drift",
+ "input_offset_voltage",
+ "input_offset_voltage_drift",
+ "input_voltage_noise_density",
+ "insertion_loss",
+ "io_count",
+ "isolation_voltage",
+ "junction_capacitance",
+ "load_capacitance",
+ "memory_size",
+ "operate_time",
+ "operating_frequency",
+ "operating_temperature",
+ "output_capacitance",
+ "output_count",
+ "output_current",
+ "output_noise_voltage",
+ "output_power",
+ "output_voltage",
+ "output_voltage_high",
+ "output_voltage_low",
+ "page_program_time",
+ "peak_pulse_current",
+ "power_dissipation",
+ "program_erase_cycles",
+ "program_memory_size",
+ "propagation_delay",
+ "psrr",
+ "quiescent_current",
+ "ram_size",
+ "rds_on",
+ "receiver_count",
+ "rectified_current",
+ "release_time",
+ "response_time",
+ "reverse_leakage_current",
+ "reverse_recovery_time",
+ "reverse_transfer_capacitance",
+ "reverse_voltage",
+ "rise_time",
+ "sample_rate",
+ "sensitivity",
+ "settling_time",
+ "slew_rate",
+ "standby_current",
+ "supply_voltage_range",
+ "switching_frequency",
+ "switching_voltage",
+ "vgs_threshold",
+ "zener_voltage"
+]compare_partsfind_partsgetget_imageget_specslookupsearchElectronic component datasheets for AI agents — specs, pinouts, package data on demand.
Search real parts with datasheet-provenance specs, check compatibility and compose priced BOMs.
Search real-time stock, pricing, and specs for electronic components on OnlineComponents.com
Search and review real KiCad and Altium PCB designs: schematics, BOMs, netlists, DRC/ERC.
Add one secure layer between your agents and this server.
