IC datasheet search: parametric part finding, spec lookup, price comparison — grounded in real PDFs.
Scored across 7 tools
Each tool targets a distinct operation: parametric constraint search (find_parts), corpus search (search), ref-based expansion (get_segments), fused lookup (lookup), canonical specs (get_specs), images (get_image), and part comparison (compare_parts). The descriptions explicitly state when to prefer lookup over search and how refs flow, so an agent should be able to select correctly.
Most tools follow a clear verb_noun snake_case pattern (compare_parts, find_parts, get_image, get_segments, get_specs). lookup and search are single verbs, which is a minor deviation but they are conventional and still readable, so the set is not confusing.
Seven tools is a well-scoped surface for an IC datasheet server: three retrieval/convenience tools, plus specs, images, parametric search, and comparison. No redundant extras or bloated set.
The surface covers searching, parametric filtering, full-text segment retrieval, canonical specs, images, and part comparison — the core datasheet workflows. The only minor gap is a single tool for pulling an entire datasheet as one document, but lookup/get_segments together make this workable.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering safety and idempotency. The description adds valuable behavioral context beyond this: it clarifies the output is a ranking from a distributor snapshot and explicitly states it is not a live quote, which alerts the agent to potential staleness. It also implies the result is a relative comparison, not absolute figures. No contradiction with annotations.
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, well-structured sentence that front-loads the core output aspects (price tier, stock posture, library class) and then adds the crucial context about being a snapshot ranking. Every phrase earns its place; there is no filler or redundancy.
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 need not explain return values. Annotations cover safety and idempotency, and the schema covers parameter requirements. The description effectively conveys the tool's purpose and the nature of its data (snapshot vs. live). The only gap is explicit usage guidance, but that is already accounted for in the usage_guidelines dimension. For its complexity, this 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 has 100% description coverage; the schema already explains the 'parts' parameter, including the requirement for two or more parts and the condition of needing at least two priced parts for a verdict. The description adds no additional meaning about the parameter itself, only restating 'a set of IC part numbers.' With full schema coverage, the baseline of 3 is appropriate.
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 the tool's function: it provides relative price tier, stock posture, and library class for IC part numbers. It specifies the resource (IC parts) and the distinct output dimensions, and the parenthetical clarifies it's a snapshot ranking rather than a live quote. This distinguishes it from typical lookup or search tools and sets clear expectations.
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 implies usage for comparing parts using distributor snapshot data, but it never explicitly states when to use this tool over its siblings (find_parts, search, lookup, etc.) or provides any exclusion conditions. The only hint is the 'not a live quote' caveat, which is more about data nature than usage context. There is no mention of alternatives or when-not-to-use.
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 meeting EVERY constraint), ranked (all parts scored, partial matches included) and returned (parts in this response). truncated means some qualifying parts are not on this page. When matched is 0 every result is a partial match. canonical MUST be one of the exact (case-sensitive) names enumerated in this tool's inputSchema, also readable as the whatic://parametric/canonicals resource.
| 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral detail: the exact return fields (per-constraint pass/fail/unknown, matched, ranked, returned), the meaning of truncated, and the special case when matched=0. This goes well beyond the annotations and gives the agent a precise model of what to expect.
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 compact yet information-dense. The first sentence captures the core purpose and ranking logic. Subsequent sentences define the output fields and edge cases. No fluff, no repetition, and the most critical constraint (canonical naming) is placed near the end but still earns its place. The structure front-loads the key behavior.
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 a complex input schema (nested constraint object with enum canonicals) and an output schema (not shown but exists). The description explains the ranking algorithm, the meaning of each output field, the 'truncated' flag, and the partial-match behavior. It also references a resource for canonical names. For an agent, everything needed to call this tool correctly and interpret results is present.
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 coverage is 100% and each parameter already has a description. The description adds a few useful extras: it explicitly warns that 'canonical' must be one of the exact case-sensitive names enumerated in the schema, and points to a canonical resource for reference. It also clarifies that 'unit' is informational only and comparisons use the stored SI value. These augment the schema meaningfully without redundancy.
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 ('Shortlist') and resource ('IC part numbers') plus the exact mechanism ('by parametric spec constraints'). It also distinguishes the tool from siblings by explaining the ranking behavior (how many constraints satisfied, headroom, family spread). This is far more specific than a generic 'search' and clearly differentiates it from compare_parts or search.
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 clearly states the tool is for parametric spec-based shortlisting, and explains the output semantics (matched, ranked, returned, truncated). It does not explicitly name alternative tools or say when NOT to use it, but the context strongly implies this is the go-to for constraint-based filtering. It lacks explicit exclusion guidance but is otherwise clear.
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?
Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds valuable behavior beyond that: it states the return payload (image plus caption/description/page metadata) and the error-record behavior with an `available_images` fallback listing nearest figures. This is rich, non-obvious context.
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?
Three sentences with no wasted words: the first states the core operation, the second the return shape, the third the failure/error behavior. The most important information is front-loaded and every sentence 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, read-only tool with strong annotations and full schema coverage, the description covers input provenance, return contents, and error behavior. Without an output schema, this is still enough for an agent to call the tool correctly and interpret likely outcomes.
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 coverage is 100% and the schema description already explains that `refs` must be opaque ref tokens and that non-image segments return an error record. The description adds provenance ('from search/lookup/get_segments') but does not materially deepen parameter semantics beyond the schema, 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 uses a specific verb and resource ('Fetch datasheet figure images (PNG/JPEG)') and clearly identifies the input as opaque `ref` tokens from search/lookup/get_segments. This distinguishes it from sibling tools, especially get_segments, by stating it returns image data rather than segments.
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 clearly implies when to use this tool: after obtaining `type='image'` ref tokens, and it warns that non-image refs produce an error record. It does not explicitly name sibling alternatives or state 'use X instead,' but the provenance and type condition give sufficient usage context.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds that refs are opaque and expanded into full content, but does not disclose additional behaviors such as rate limits, authentication requirements, or error handling. Since annotations cover the core behavioral traits, the description's added value is minimal.
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, front-loaded sentence that directly states the action and purpose. There is no wasted wording or redundant information, making it highly concise and well-structured.
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 that the tool has an output schema, the description need not explain return values. The description covers what the tool does and where refs originate, which is sufficient for a simple one-parameter operation. It does not mention edge cases or invalid input handling, but the word 'opaque' implies that refs should be used as-is, and the output schema provides the expected return structure. Overall, it is complete enough for an agent to call the 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 coverage is 100% because the parameter 'refs' has a description identical to the tool description ('Opaque ref tokens from search/lookup hit records, to expand into full segment content'). The tool description does not add any extra meaning beyond what the schema already provides, so it meets the baseline for high coverage without adding value.
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 the verb 'Expand' and the resource 'opaque ref tokens' with a specific outcome 'full datasheet segment content'. It distinguishes itself from sibling tools like search, lookup, and get_specs by focusing solely on expanding refs into segment content, which is a unique operation among the listed siblings.
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 search/lookup' provides context that this tool is intended to be used after those operations, implying a prerequisite. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any scenarios where it should not be used. The guidance is implied rather than explicit.
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?
The description adds important behavioral context beyond the annotations: absence from results means no index coverage, not that the datasheet lacks the parameter, and a 'No specs found' warning is emitted. It also clarifies the source is a pre-extracted index, not raw datasheet text, which shapes agent expectations about result semantics.
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 compact and front-loaded, opening with the core purpose and source distinction before giving usage guidance and caveats. Every sentence contributes necessary information; there is no filler or redundancy.
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 output schema exists and the annotations already convey read-only and open-world behavior, the description covers the remaining operational context: when to use the tool, what absence means, and which sibling to fall back to. The agent has enough information 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%, so the schema already documents both parameters, including family fallback and canonical names. The description adds only light context by mentioning canonical parameter names and optional restriction, but does not substantially improve on 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 and resource: it reads canonical extracted specs for known IC part numbers from a pre-extracted parametric index. It explicitly differentiates itself from datasheet text and names lookup as the fallback, so the agent can distinguish it from siblings without opening schemas.
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 explicitly says this is the cheapest and most precise source for numeric parameters where it has coverage, and gives a clear fallback instruction to use lookup when a part is absent from results. This is direct when-to-use and when-not-to-use guidance with a named alternative.
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?
Annotations already cover readOnly and idempotent, so the description adds value by stating results are grouped per part and full content is returned. No contradiction with annotations.
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 concise sentences, front-loaded with purpose, with no redundant wording.
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?
Covers purpose, usage, and key behavior; output schema handles return details. Missing explicit exclusions (e.g., when parts unknown) but implied. Reasonably 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?
Schema covers both parameters with descriptions (100% coverage), so baseline is 3. The description reinforces the grouping role of parts but adds little 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 clearly states the tool retrieves full content of datasheet segments for one or more parts, and explicitly differentiates it from siblings by noting it fuses search+get_segments and should be preferred over search when parts are known.
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 explicitly names the alternative (search) and the condition (when you know the part(s)) for preferring lookup. This is direct routing guidance.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description doesn't need to restate those. It adds valuable behavioral context: that hits contain opaque refs, that refs are passed to `get_segments` for full content, and that part-specific scoping prevents cross-part contamination. This exceeds the baseline for annotation-backed tools without being redundant.
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 well-structured and front-loaded: the main purpose and return shape come first, followed by routing guidance and a scoping example. It is somewhat long but every sentence contributes actionable information, and the length is justified by the tool's role in a workflow. Minor redundancy with the schema's scope description prevents a 5.
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, the presence of an output schema, and rich annotations, the description covers everything an agent needs: what results look like, how to proceed to full content (get_segments), when to choose the alternative (lookup), and how to restrict scope. The workflow is fully described without needing return-value details because the output schema exists.
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 per the rubric the baseline is 3. The description does not add parameter meaning beyond the schema: the `q` example and the `scope='device:NE5532'` instruction are already present in the input schema's property descriptions. No additional semantics are introduced, so a 3 is appropriate.
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 and resource: 'Search the datasheet corpus' and explicitly describes the return shape (hit records with metadata, snippet, and opaque ref). It distinguishes from the sibling `lookup` by clarifying that `lookup` is preferred when part numbers are known. An agent can tell this apart from all sibling tools without opening schemas.
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 gives explicit routing guidance: 'prefer `lookup`' when part numbers are known, and 'Use `search` when the part is unknown, or to triage snippets'. It also provides concrete scoping advice (scope='device:<MPN>') to avoid cross-part contamination. This is exactly the kind of when-to-use vs. alternatives guidance that agents need.
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.
find_parts1 field changedInput schema / $defs / Constraint / properties / canonical / descriptionPrevious value: -"Canonical parameter name (see the whatic://parametric/canonicals resource or this tool's description for the exact set), e.g. supply_voltage_range."New value: +"Canonical parameter name, e.g. supply_voltage_range — must be one of the values enumerated for this field (also readable as the whatic://parametric/canonicals resource)."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
Find products by description or Bill of Materials, over 100k+ suppliers and products
Add one secure layer between your agents and this server.
