Electronic component datasheets for AI agents — specs, pinouts, package data on demand.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.8/5 across 12 of 12 tools scored.
Each tool has a clearly distinct purpose: search_parts finds parts, search_datasheets searches extracted content, read_datasheet reads sections, analyze_image extracts visual data, compare_parts batches comparisons, find_alternative finds substitutes, check_design_fit validates specs, prefetch/check/manage extraction status, and request/confirm handle uploads. The descriptions cross-reference each other to further eliminate ambiguity.
All 12 tools follow the verb_noun snake_case pattern consistently (analyze_image, check_design_fit, compare_parts, prefetch_datasheets, request_datasheet_upload, etc.). No mixing of camelCase, verb styles, or vague generic names.
12 tools is ideal for a datasheet-centric server, covering the full workflow from part discovery and datasheet extraction to analysis, validation, comparison, and upload. The count is neither bloated nor thin, and every tool earns its place.
The tool surface is comprehensive for the domain: part search, spec-based semantic search, detailed part data, datasheet reading (section/search), image analysis, design-fit checking, part comparison, alternative finding, extraction lifecycle management, and manual datasheet upload (request+confirm). No obvious dead ends or critical missing operations.
analyze_imageAAnalyze an image from a component's datasheet using vision AI. Use this when read_datasheet returns a section containing images and you need to extract data from a graph, package drawing, pin diagram, or circuit schematic. Pass the image_key from the read_datasheet response (the storage path in the image URL). Optionally pass a specific question to focus the analysis.
IMPORTANT: For precise numeric values (electrical specs, max ratings), prefer read_datasheet text tables first — they are more reliable than vision-extracted graph data. Use analyze_image for visual information not available in text: package dimensions from drawings, pin assignments from diagrams, graph trends, and approximate values from characteristic curves.
Examples:
analyze_image(part_number='IRFZ44N', image_key='images/abc123.png') -> classifies and describes the image
analyze_image(part_number='IRFZ44N', image_key='images/abc123.png', question='What is the drain current at Vgs=5V?')
| Name | Required | Description | Default |
|---|---|---|---|
| question | No | Optional specific question about the image (e.g. 'What are the package dimensions?') | |
| image_key | Yes | Image storage path from read_datasheet output (e.g. 'images/abc123.png') | |
| part_number | Yes | MPN of the component |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, providing the base safety profile. The description adds valuable context about the reliability of vision-extracted data versus text tables and explains the dependency on image_key from read_datasheet, which are behavioral traits not covered by 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 well-structured: it front-loads the purpose, then provides usage guidance, an important caveat, and examples. It is slightly long but every sentence contributes value, and the formatting with an IMPORTANT section and examples improves scannability.
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 there is no output schema, the description adequately conveys what the tool returns through examples (e.g., classifies and describes the image). It also covers the workflow dependency on read_datasheet and the trade-offs between vision and text extraction, making it sufficiently complete for correct invocation.
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%, so parameter basics are already documented. The description enhances this with usage examples showing how image_key and question interact, and clarifies that image_key is the storage path from read_datasheet output, adding relational 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 clearly states the tool analyzes images from datasheets using vision AI, with a specific verb ('Analyze') and resource (image from a component's datasheet). It distinguishes itself from read_datasheet by specifying it handles visual data like graphs, package drawings, pin diagrams, and circuit schematics.
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 when to use this tool (when read_datasheet returns images needing extraction) and when not to use it (for precise numeric values, where read_datasheet text tables are preferred). It names the alternative tool, read_datasheet, and provides concrete examples of appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_design_fitAValidate whether a component will work within your operating conditions. Compares your design parameters against the datasheet's absolute maximum ratings and recommended operating conditions. Returns PASS/FAIL/WARNING per parameter with margin percentages.
Parameter mapping by component type:
Buck/boost converters: input_voltage, output_voltage, output_current, ambient_temp
MOSFETs: supply_voltage=VDS, output_current=ID (drain current), ambient_temp
LDOs: input_voltage, output_voltage, output_current, ambient_temp
Logic ICs: supply_voltage=VCC, ambient_temp
Result semantics (per-parameter 'result' field):
PASS: comfortable margin. For a recommended-operating RANGE, any value inside the range (including the exact edges) is PASS. For an absolute-MAX rating, PASS means more than 10% below the limit.
WARNING: for absolute-max ratings only, the user value is within 10% of the limit (but not over) — part will work but with thin margin for part-to-part variation, temperature drift, and transients. Consider derating.
FAIL: user value is outside the allowed range / exceeds the limit — part is out of spec and will be stressed or damaged.
INSUFFICIENT_DATA: the check could not be completed safely — most commonly an ambient_temp input that could not be translated to a junction-temperature check (see the temperature note below). INSUFFICIENT_DATA never counts as a PASS: it pulls the overall verdict down to at-least-WARNING. Each check also reports 'limit_type' (max / min / range / fixed) so you can see whether it was judged against an operating range, an absolute-max rating, or a fixed-output setpoint.
Temperature honesty:
ambient_temp is NOT silently treated as a junction temperature. The stored operating-temperature limit is junction-suspect, so a bare ambient input is never reported as a clean PASS on thermal grounds. If you also supply input_voltage, output_voltage and output_current AND a thermal-resistance (RthJA) value is available, the tool estimates Tj = Ta + Pd·RthJA (Pd ≈ (Vin-Vout)·Iout, a documented approximation) and checks the junction estimate — reported as 'temperature (junction est.)' with the assumptions in the note. Otherwise the temperature check returns INSUFFICIENT_DATA asking you to pull RthJA via read_datasheet. The 'temperature_basis' field (junction / ambient / unknown) tells you which basis was used.
Behavior:
Two-tier validation. For parameters in our structured database (Vin, Iout, operating temp, etc.), returns instantly and free of LLM cost. For parameters only found in the datasheet text, falls back to an LLM read of the absolute-max and recommended-operating-conditions sections. The 'validation_method' field in the response tells you which path was used.
If the part hasn't been extracted yet and the LLM fallback is needed, this call triggers extraction (30s-2min). Returns status='extracting' if so — poll check_extraction_status and retry.
When NOT to use:
You need power dissipation or junction-temperature rise — this tool only checks nameplate limits. Pull RthJA from read_datasheet and calculate yourself.
You need SOA (safe-operating-area) curve checks for MOSFETs — use analyze_image on the SOA graph.
You're checking a passive or mechanical part with no abs-max table — there's nothing for this tool to compare against.
Example: check_design_fit('TPS54302', input_voltage=24, output_current=2.5, ambient_temp=70)
| Name | Required | Description | Default |
|---|---|---|---|
| part_number | Yes | Specific manufacturer part number to validate. Not a value or description. | |
| ambient_temp | No | Ambient temperature TA (°C). | |
| input_voltage | No | Input voltage / VIN (V). For converters. | |
| output_current | No | Output current / IOUT (A). For MOSFETs, this is drain current ID. | |
| output_voltage | No | Output voltage / VOUT (V). For converters/LDOs. | |
| supply_voltage | No | Supply voltage / VCC / VDD (V). For MOSFETs, this is VDS (drain-source voltage). NOT used for power dissipation — compared against VDS(max) only. | |
| switching_frequency | No | Switching frequency FSW (kHz). For converters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint/destructiveHint annotations, the description reveals non-obvious behaviors: two-tier validation (structured DB vs LLM fallback), side-effect of triggering extraction with a 30s-2min delay, honest temperature handling (not silently treating ambient as junction), and explicit result semantics (PASS/WARNING/FAIL/INSUFFICIENT_DATA). 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 structured with clear section headers (Parameter mapping, Result semantics, Temperature honesty, Behavior, When NOT to use), front-loads the core purpose, and includes an illustrative example. Every sentence adds unique information, and the length is proportional to the tool's complexity.
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 absence of an output schema, the description thoroughly explains return fields (result, limit_type, validation_method, temperature_basis) and covers all parameter semantics, edge cases (INSUFFICIENT_DATA), and side effects. It is self-contained for safe and effective use, including limitations and alternatives.
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?
Even though schema description coverage is 100%, the description adds significant layer-valued context: component-type-to-parameter mapping (Buck/boost, MOSFET, LDO, Logic ICs), clarification that supply_voltage maps to VDS for MOSFETs, and the distinction between ambient_temp and junction-temperature estimation. This goes far beyond the literal schema definitions.
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 precise verb ('Validate whether a component will work within your operating conditions') and clearly states the comparison against datasheet absolute maximum ratings and recommended operating conditions. It distinguishes itself from sibling tools like read_datasheet and analyze_image by defining its unique role in design validation, reinforced by an example.
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 'When NOT to use' section explicitly lists three exclusion scenarios with alternative tools (power dissipation → read_datasheet, SOA curves → analyze_image, passive/mechanical parts → no tool). It also explains when to use the tool (validating design parameters) and provides process guidance on handling the 'extracting' status through check_extraction_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_extraction_statusACheck the extraction status of one or more parts. Free. Each entry includes the current extraction step, elapsed seconds, and document ID.
Use after prefetch_datasheets or after read_datasheet triggers a new extraction.
Recommended polling cadence: every 5-10 seconds. Extraction typically takes 30s-2min for new parts, so polling faster than every 5s wastes calls. Stop polling once status is 'ready', 'failed', 'no_source', or 'unsupported'.
DATASHEET STATUS VALUES:
'ready' — extracted and indexed; call read_datasheet, search_datasheets, or analyze_image.
'extracting' / 'in_progress' / 'queued' / 'pending' — extraction running or scheduled. Poll check_extraction_status every 5-10s until 'ready' or 'failed'. Typical time: 30s-2min.
'not_extracted' — known part but datasheet hasn't been fetched yet. Trigger it via prefetch_datasheets (cheapest) or by calling read_datasheet (auto-triggers on first read).
'no_source' — we couldn't find a public datasheet URL for this MPN. First, retry prefetch_datasheets in 10-30s (the URL resolver re-runs and often finds a source on the second pass). If still 'no_source', the agent can upload the PDF manually via request_datasheet_upload + confirm_datasheet_upload (see those tools). Org-uploaded datasheets are private to the org.
'unsupported' — PDF exists but can't be extracted (scanned image-only, encrypted, or corrupted). Upload a clean text-based PDF via request_datasheet_upload to override.
'failed' / 'error' — extraction errored. The response includes the error reason. Retry via prefetch_datasheets or escalate to support.
'rejected' — input wasn't a real MPN (bare value like '100nF', description, or reference designator). Fix the input and re-call.
'deduplicated' — another part in the family already has this datasheet; same content is returned under the primary MPN.
| Name | Required | Description | Default |
|---|---|---|---|
| part_numbers | Yes | 1-20 MPNs to check. Must be specific manufacturer part numbers, not values or descriptions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds rich behavioral context beyond annotations: it is free, includes elapsed seconds and document ID, explains the meaning of every status value, notes that no_source may resolve on retry, and discloses that org-uploaded datasheets are private. This goes well beyond the readOnly/idempotent hints, with no contradictions.
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 front-loaded with the purpose and usage, then organized into a clear status-value list. Every sentence provides actionable information; the length is justified by the number of distinct statuses and the need to give follow-up actions for each.
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 no output schema, the description fully compensates by enumerating all possible statuses, typical durations, recommended polling, and next-step actions. It also notes response contents (step, elapsed seconds, document ID, error reason), making it complete for practical use.
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 parameter description already explains MPN requirements. The tool's description adds value by explaining the 'rejected' status as a consequence of invalid inputs, and clarifies that each entry corresponds to a part number, reinforcing the semantics 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 clearly states the tool checks extraction status of one or more parts, with a specific verb and resource. It distinguishes itself from siblings like prefetch_datasheets and read_datasheet by focusing on status polling and listing terminal states.
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?
Explicit guidance is given on when to use: after prefetch_datasheets or when read_datasheet triggers extraction. It provides polling cadence, stopping conditions, and specific alternative tools for each non-ready status (e.g., prefetch_datasheets for not_extracted, request/confirm upload for no_source/unsupported).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_partsACompare 2-5 electronic components side by side in a single call. For each part, returns merged provider data (pricing, stock, structured parameters, package) plus the cached datasheet summary if one exists, plus datasheet_status ('ready', 'extracting', or 'not_extracted').
Use this instead of calling get_part_details in a loop — it fans out provider queries in parallel and merges by MPN. For discovering candidates, use search_parts or find_alternative first; compare_parts assumes you already know which MPNs you want to compare.
Behavior:
Uses only cached datasheet summaries — does not trigger extraction. Call prefetch_datasheets first if you need summaries for parts that haven't been extracted yet.
Validates every MPN upfront. If any input is not a real part number (value, description, reference designator), the whole call is rejected with a 'rejected' map listing the offenders — other parts are not compared. Filter your list before calling.
If a valid MPN is not found at any provider, that part still appears in the response with an 'error' field; the other parts are compared normally.
IMPORTANT — part_numbers must be specific manufacturer part numbers (e.g. 'TPS54302DDCR', 'STM32F446RCT6') or LCSC numbers (e.g. 'C2837938'). Do NOT pass component values ('100nF', '10K'), descriptions ('buck converter'), or reference designators ('U3', 'R1').
Example: compare_parts(['TPS54302', 'LM2596', 'MP2359'])
DATASHEET STATUS VALUES:
'ready' — extracted and indexed; call read_datasheet, search_datasheets, or analyze_image.
'extracting' / 'in_progress' / 'queued' / 'pending' — extraction running or scheduled. Poll check_extraction_status every 5-10s until 'ready' or 'failed'. Typical time: 30s-2min.
'not_extracted' — known part but datasheet hasn't been fetched yet. Trigger it via prefetch_datasheets (cheapest) or by calling read_datasheet (auto-triggers on first read).
'no_source' — we couldn't find a public datasheet URL for this MPN. First, retry prefetch_datasheets in 10-30s (the URL resolver re-runs and often finds a source on the second pass). If still 'no_source', the agent can upload the PDF manually via request_datasheet_upload + confirm_datasheet_upload (see those tools). Org-uploaded datasheets are private to the org.
'unsupported' — PDF exists but can't be extracted (scanned image-only, encrypted, or corrupted). Upload a clean text-based PDF via request_datasheet_upload to override.
'failed' / 'error' — extraction errored. The response includes the error reason. Retry via prefetch_datasheets or escalate to support.
'rejected' — input wasn't a real MPN (bare value like '100nF', description, or reference designator). Fix the input and re-call.
'deduplicated' — another part in the family already has this datasheet; same content is returned under the primary MPN.
| Name | Required | Description | Default |
|---|---|---|---|
| part_numbers | Yes | 2-5 specific manufacturer part numbers or LCSC numbers to compare head-to-head. Must be real MPNs — the call is rejected upfront if any entry is a value, description, or reference designator. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses numerous behavioral traits beyond annotations: uses only cached datasheet summaries (does not trigger extraction), validates all MPNs upfront and rejects the entire call if any is invalid, returns per-part 'error' fields for missing parts while still comparing valid ones. This adds rich context that annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) do not cover.
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 with purpose, usage, and a clear example. The extended DATASHEET STATUS VALUES section is informative but somewhat long and contains guidance tangential to compare_parts itself (e.g., retry logic, upload instructions). Still, every section earns its place for a complex tool with no output schema.
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 no output schema, the description thoroughly explains return values (merged provider data fields, cached datasheet summary, datasheet_status) and edge cases (invalid MPN rejection, missing provider handling, status meanings). It even provides an example call and covers all possible datasheet_status values, making the tool fully usable without external references.
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?
Even though the schema covers the parameter (100%), the description significantly enriches understanding by providing concrete examples ('TPS54302DDCR', 'C2837938'), explicitly prohibiting values/descriptions/reference designators, and explaining the rejection behavior. It also clarifies LCSC numbers are allowed, which is not obvious from 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 specific verb 'Compare' and resource '2-5 electronic components' in a single call, listing the exact outputs (pricing, stock, structured parameters, package, datasheet_status). It distinguishes itself from siblings by explicitly framing it as an alternative to get_part_details in a loop and noting it's not for discovery (unlike search_parts/find_alternative).
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 states when to use this tool instead of get_part_details in a loop (parallel fan-out, merge by MPN), and when NOT to use it (for discovery, use search_parts or find_alternative first). Also gives guidance on prefetch_datasheets for missing summaries. This is textbook usage differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
confirm_datasheet_uploadAConfirm a datasheet upload started via request_datasheet_upload. Pass the upload_token you got back from the request step. The server downloads the uploaded bytes, re-hashes to verify integrity, validates that it's a real PDF with the MPN on the first page, creates the private Document + Component records, charges the upload fee (50¢), and queues extraction.
Success response: document_id, mpn, sha256, file_size_bytes, status='pending'. Poll check_extraction_status with the MPN to wait for extraction to finish (30s-2min typically).
Failure modes:
'upload_not_found' — no bytes at the upload URL yet. Retry your curl upload.
'sha256_mismatch' — uploaded bytes hash differs from expected_sha256. Re-compute the hash and re-request.
'invalid_pdf' — bytes aren't a parseable PDF. No charge.
'mpn_not_in_pdf' — MPN (or its stem) isn't on the first page. Either you uploaded the wrong file or it's a scanned image-only PDF. No charge.
'token_expired' — upload token is older than 15 minutes. Restart via request_datasheet_upload.
| Name | Required | Description | Default |
|---|---|---|---|
| upload_token | Yes | Opaque token returned by request_datasheet_upload. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as destructive and not read-only, but the description adds specific behavioral details: it creates private Document + Component records, charges a 50¢ upload fee, and queues extraction. It also discloses token expiry (15 minutes) and which failures incur no charge, going beyond the 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 well-structured: an overview sentence, a success response block, and a failure-mode list. Every sentence provides actionable information without filler, and the bullet-style failure modes are easy to scan. It is appropriately concise for a tool with multiple side effects and error conditions.
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?
Without an output schema, the description fully specifies the success response (document_id, mpn, sha256, file_size_bytes, status) and directs to check_extraction_status for progress. It enumerates all likely failure modes with conditions and remedies, making the tool's behavior completely predictable.
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 schema already describes upload_token as an opaque token from request_datasheet_upload (100% coverage). The description adds practical semantics: the token ties to the uploaded bytes, has a 15-minute expiry, and must be passed as-is, enriching the schema's information.
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 confirms a datasheet upload initiated by request_datasheet_upload, specifying the exact verb 'Confirm' and the resource. It also distinguishes this step from the request and check_extraction_status siblings by outlining the subsequent actions (creating records, charging fee, queuing extraction).
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 explicitly places this tool after request_datasheet_upload and instructs to poll check_extraction_status upon success. Each failure mode includes a remediation step (e.g., retry curl upload, re-request, restart via request_datasheet_upload), providing clear next actions and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_alternativeAFind alternative / second-source components for a given MPN. Returns parts ranked by how closely their specs, package, and category match the reference part, with a match_score and match_notes explaining each match.
When to use:
Original part is out of stock or end-of-life.
You need a cheaper equivalent with similar specs.
You need a second source for supply-chain resilience.
You need a drop-in replacement on an existing PCB (use constraints=['same_package']).
When NOT to use:
You're browsing a category from scratch — use search_parts.
You already have candidates and want a head-to-head comparison — use compare_parts directly.
Behavior:
Eval boards, dev kits, and breakout modules are filtered out — results are IC-level alternatives only.
'same_package' uses fuzzy matching, so SOT-23 ≡ SOT23, SOIC-8 ≡ SOP-8, LQFP64 ≡ TQFP64, etc. Exact string match is not required.
If provider search returns few candidates, the tool falls back to semantic search across extracted datasheets to surface niche alternatives.
The response includes a 'hint' field pointing to compare_parts / read_datasheet for drilling into promising alternatives.
Example: find_alternative('TPS54302', constraints=['same_package', 'in_stock'])
DATASHEET STATUS VALUES:
'ready' — extracted and indexed; call read_datasheet, search_datasheets, or analyze_image.
'extracting' / 'in_progress' / 'queued' / 'pending' — extraction running or scheduled. Poll check_extraction_status every 5-10s until 'ready' or 'failed'. Typical time: 30s-2min.
'not_extracted' — known part but datasheet hasn't been fetched yet. Trigger it via prefetch_datasheets (cheapest) or by calling read_datasheet (auto-triggers on first read).
'no_source' — we couldn't find a public datasheet URL for this MPN. First, retry prefetch_datasheets in 10-30s (the URL resolver re-runs and often finds a source on the second pass). If still 'no_source', the agent can upload the PDF manually via request_datasheet_upload + confirm_datasheet_upload (see those tools). Org-uploaded datasheets are private to the org.
'unsupported' — PDF exists but can't be extracted (scanned image-only, encrypted, or corrupted). Upload a clean text-based PDF via request_datasheet_upload to override.
'failed' / 'error' — extraction errored. The response includes the error reason. Retry via prefetch_datasheets or escalate to support.
'rejected' — input wasn't a real MPN (bare value like '100nF', description, or reference designator). Fix the input and re-call.
'deduplicated' — another part in the family already has this datasheet; same content is returned under the primary MPN.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max alternatives to return (default 5, max 20). | |
| constraints | No | Optional filters to narrow alternatives. 'in_stock' = only parts with non-zero stock at any provider. 'same_package' = package footprint must match (fuzzy). 'jlcpcb' = must be available at JLCPCB (useful for JLCPCB-assembled boards — also restricts the provider search to JLCPCB). | |
| part_number | Yes | The MPN to find alternatives for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only/idempotent/non-destructive. The description adds substantial behavioral context: filters out eval boards and dev kits, fuzzy package matching, fallback to semantic search, a 'hint' field, and exhaustive datasheet status handling. 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 long but well-organized with labeled sections and front-loaded core purpose. The datasheet status block is verbose, but it is directly relevant to interpreting returned matches and justifies its length. No filler sentences.
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?
No output schema exists, so the description carries the responsibility of explaining return values. It does so: match_score, match_notes, hint field, and datasheet statuses are all described. It also covers edge cases, fallback behavior, and when not to use the tool, making it self-sufficient.
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%, so parameters are already documented. The description adds value by explaining fuzzy matching behavior for 'same_package' and showing realistic usage via the constraints example. It does not fully explain 'limit' or 'part_number' beyond what schema provides, but the addition is meaningful.
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: 'Find alternative / second-source components for a given MPN.' It clearly states what the tool does and distinguishes it from siblings by mentioning search_parts for browsing and compare_parts for direct comparison.
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?
Dedicated 'When to use' and 'When NOT to use' sections explicitly name alternatives (search_parts, compare_parts) and give concrete scenarios (out of stock, cheaper equivalent, drop-in replacement). Even includes a usage example with constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_part_detailsAGet full details for a specific electronic component by manufacturer part number (MPN) or LCSC number. Returns specs, pricing, and stock from all configured providers, plus the cached datasheet summary if available. Includes datasheet_status and available_sections when ready. Set prefetch_datasheet=true to trigger background extraction — no extra charge. Use after search_parts to drill into a specific result.
The part_number must be a specific manufacturer part number (e.g. 'TPS54302DDCR', 'STM32F446RCT6') or LCSC number (e.g. 'C2837938'). Do NOT pass bare component values ('100nF', '10K'), descriptions ('buck converter'), or reference designators ('R1', 'U3').
DATASHEET STATUS VALUES:
'ready' — extracted and indexed; call read_datasheet, search_datasheets, or analyze_image.
'extracting' / 'in_progress' / 'queued' / 'pending' — extraction running or scheduled. Poll check_extraction_status every 5-10s until 'ready' or 'failed'. Typical time: 30s-2min.
'not_extracted' — known part but datasheet hasn't been fetched yet. Trigger it via prefetch_datasheets (cheapest) or by calling read_datasheet (auto-triggers on first read).
'no_source' — we couldn't find a public datasheet URL for this MPN. First, retry prefetch_datasheets in 10-30s (the URL resolver re-runs and often finds a source on the second pass). If still 'no_source', the agent can upload the PDF manually via request_datasheet_upload + confirm_datasheet_upload (see those tools). Org-uploaded datasheets are private to the org.
'unsupported' — PDF exists but can't be extracted (scanned image-only, encrypted, or corrupted). Upload a clean text-based PDF via request_datasheet_upload to override.
'failed' / 'error' — extraction errored. The response includes the error reason. Retry via prefetch_datasheets or escalate to support.
'rejected' — input wasn't a real MPN (bare value like '100nF', description, or reference designator). Fix the input and re-call.
'deduplicated' — another part in the family already has this datasheet; same content is returned under the primary MPN.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Which provider to query: 'all' (default), 'jlcpcb', 'mouser', or 'digikey' | all |
| part_number | Yes | Specific manufacturer part number (MPN) or LCSC number (e.g. 'C2837938'). Not a value or description. | |
| prefetch_datasheet | No | Trigger background datasheet extraction (no extra charge). Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true and destructiveHint=false, and the description goes far beyond by explaining prefetch_datasheet behavior, no extra charge, and a complete datasheet status lifecycle with recommended polling intervals and retry actions. This adds significant context about asynchronous behavior and error handling without contradicting the 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 long but well-structured: a clear opening summary, usage guidance, and a detailed datasheet status section formatted as a list. Every status value earns its place because it informs actionable next steps, though a few redundant phrases like 'extraction running or scheduled' could have been trimmed.
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 complexity (multiple statuses, background extraction, provider options) and no output schema, the description is comprehensive. It covers what the tool does, what it returns, how to handle each datasheet state, and pointers to related tools for additional actions, making it self-sufficient for an agent.
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% with each parameter having a description, but the narrative adds extra meaning: real MPN examples, explicit negative examples for part_number, and semantic details about prefetch_datasheet as a background trigger with no charge. This far exceeds the schema's basic field descriptions.
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 it fetches full details for a component by MPN/LCSC number and lists return contents (specs, pricing, stock, datasheet summary). It uses a specific verb ('Get full details') and resource ('specific electronic component'), differentiating it from search_parts and other 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?
Explicitly instructs to use after search_parts to drill into a result, and provides concrete restritions on what part_number should NOT contain (bare values, descriptions, reference designators). The extensive datasheet status section also recommends when to call check_extraction_status, read_datasheet, prefetch_datasheets, or upload tools, giving clear alternative routes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prefetch_datasheetsATrigger background datasheet extraction for multiple parts at once (up to 20). Non-blocking — returns immediately with the status of each part. Use this to warm up datasheets for a BOM before calling read_datasheet. Example: prefetch_datasheets(['TPS54302', 'ADS1115', 'LP5907'])
If a part comes back 'no_source' on the first call, retry prefetch for that MPN once after 10-30s — the URL resolver is retriable and often finds a source on the second pass. If still 'no_source', use request_datasheet_upload + confirm_datasheet_upload to attach your own PDF (org-private).
Part numbers must be specific MPNs (e.g. 'STM32F446RCT6', 'TPS54302DDCR') or LCSC numbers (e.g. 'C2837938'). Do NOT pass bare values ('100nF', '10K'), descriptions, BOM reference designators, test points, or board/module names — see the server instructions for the full rule set. When a BOM has values-only rows, use search_parts first to resolve each to an MPN.
DATASHEET STATUS VALUES:
'ready' — extracted and indexed; call read_datasheet, search_datasheets, or analyze_image.
'extracting' / 'in_progress' / 'queued' / 'pending' — extraction running or scheduled. Poll check_extraction_status every 5-10s until 'ready' or 'failed'. Typical time: 30s-2min.
'not_extracted' — known part but datasheet hasn't been fetched yet. Trigger it via prefetch_datasheets (cheapest) or by calling read_datasheet (auto-triggers on first read).
'no_source' — we couldn't find a public datasheet URL for this MPN. First, retry prefetch_datasheets in 10-30s (the URL resolver re-runs and often finds a source on the second pass). If still 'no_source', the agent can upload the PDF manually via request_datasheet_upload + confirm_datasheet_upload (see those tools). Org-uploaded datasheets are private to the org.
'unsupported' — PDF exists but can't be extracted (scanned image-only, encrypted, or corrupted). Upload a clean text-based PDF via request_datasheet_upload to override.
'failed' / 'error' — extraction errored. The response includes the error reason. Retry via prefetch_datasheets or escalate to support.
'rejected' — input wasn't a real MPN (bare value like '100nF', description, or reference designator). Fix the input and re-call.
'deduplicated' — another part in the family already has this datasheet; same content is returned under the primary MPN.
| Name | Required | Description | Default |
|---|---|---|---|
| part_numbers | Yes | List of MPNs to prefetch (max 20). Must be specific manufacturer part numbers, not values or descriptions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses non-blocking behavior, return statuses, retriability, and failure modes in detail. Annotations already declare readOnlyHint and no destructiveHint, and the description consistently aligns with those while adding operational context (e.g., status meanings and retry timing).
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 long but every section earns its place. It is front-loaded with purpose and an example, then systematically organizes status values and retry logic. The structured bullet points make it 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?
Given the lack of an output schema, the description fully explains the possible status values and their implications. It covers prerequisites, failure handling, and alternatives, making it complete for an agent to act on.
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 schema covers the parameter but the description adds substantial meaning: concrete examples ('TPS54302'), allowed formats (MPNs, LCSC numbers), prohibited inputs ('100nF', descriptions, reference designators), and a workflow for resolving BOM values via search_parts.
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 action: 'Trigger background datasheet extraction for multiple parts at once (up to 20).' It clearly distinguishes this tool from siblings like read_datasheet and check_extraction_status by emphasizing its role as a prefetch/warm-up step.
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?
Explicit when-to-use guidance is given: 'Use this to warm up datasheets for a BOM before calling read_datasheet.' It also provides specific alternatives for failure cases (retry, request_datasheet_upload) and exclusions (do not pass bare values, use search_parts for values-only rows).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_datasheetARead from a component's datasheet. Two modes:
Section mode (default): Returns a named section. Start with section='summary' to get an overview and a list of available_sections. Then request specific sections by name. Section names are dynamic — any heading in the actual datasheet works (e.g. 'register_map', 'i2c_interface', 'power_management'). If a section name isn't found, automatically falls back to search mode.
Search mode: Semantic search within the part's datasheet. Best for targeted questions (register bit fields, I2C config, specific specs). Use when you need to find specific information rather than a whole section.
First call for a new part triggers extraction (30s-2min). Subsequent calls are cached.
Datasheet vs Reference Manual: Manufacturer datasheets cover high-level specs, pinout, absolute maximum ratings, and package info. For microcontrollers (STM32, nRF52, RP2040), register-level programming details (I2C CR1/CR2, DMA config, interrupt bits) are in a separate Reference Manual, not the datasheet. The summary's available_sections will show what's actually present.
The part_number must be a specific manufacturer part number (e.g. 'TPS54302', 'STM32F446RCT6') or LCSC number (e.g. 'C2837938'). Do NOT pass bare component values ('100nF', '10K'), descriptions, or reference designators.
DATASHEET STATUS VALUES:
'ready' — extracted and indexed; call read_datasheet, search_datasheets, or analyze_image.
'extracting' / 'in_progress' / 'queued' / 'pending' — extraction running or scheduled. Poll check_extraction_status every 5-10s until 'ready' or 'failed'. Typical time: 30s-2min.
'not_extracted' — known part but datasheet hasn't been fetched yet. Trigger it via prefetch_datasheets (cheapest) or by calling read_datasheet (auto-triggers on first read).
'no_source' — we couldn't find a public datasheet URL for this MPN. First, retry prefetch_datasheets in 10-30s (the URL resolver re-runs and often finds a source on the second pass). If still 'no_source', the agent can upload the PDF manually via request_datasheet_upload + confirm_datasheet_upload (see those tools). Org-uploaded datasheets are private to the org.
'unsupported' — PDF exists but can't be extracted (scanned image-only, encrypted, or corrupted). Upload a clean text-based PDF via request_datasheet_upload to override.
'failed' / 'error' — extraction errored. The response includes the error reason. Retry via prefetch_datasheets or escalate to support.
'rejected' — input wasn't a real MPN (bare value like '100nF', description, or reference designator). Fix the input and re-call.
'deduplicated' — another part in the family already has this datasheet; same content is returned under the primary MPN.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Reading mode: 'section' (default) returns a named section, 'search' does semantic search | section |
| limit | No | Max search results for search mode (default 10). Each result includes adjacent context chunks for continuity. | |
| query | No | Search query — REQUIRED when mode='search', ignored when mode='section'. Example: 'charge voltage register', 'I2C address'. | |
| section | No | Section name for section mode. Start with 'summary' to discover available sections. Common: summary, pinout, electrical, abs_max, register_map, timing, package. Any heading in the datasheet works (slugified). | summary |
| part_number | Yes | Specific manufacturer part number (MPN) or LCSC number. Not a value or description. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and non-destructive behavior, the description discloses that first calls trigger extraction (30s-2min), that section names are dynamic and fall back to search, and provides exhaustive status value semantics. It also explains that register-level details are not in the datasheet for MCUs, preventing incorrect expectations.
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 long but densely organized with bold section headers (Section mode, Search mode, Datasheet vs Reference Manual, DATASHEET STATUS VALUES). Each segment earns its place, delivering actionable guidance rather than fluff, though the status value enumeration is extensive and could arguably be trimmed or moved to a linked reference.
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 complexity (5 params, no output schema), the description is remarkably complete: it covers prerequisite extraction, caching, status handling, error escalation, and even context about datasheet vs reference manual. The agent is fully equipped to decide when and how to call this tool without needing external knowledge.
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?
While the input schema covers all five parameters, the description adds critical meaning beyond the schema: part_number must be a specific MPN or LCSC number (not bare values), section mode should start with 'summary', and search mode requires a query. It gives concrete examples and explains how section names are dynamic slugified headings, supplementing the schema's basic type enums.
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 'Read from a component's datasheet', a specific verb+resource, and then details two modes (section and search). It distinguishes from sibling tools like search_datasheets by focusing on reading within a single part's datasheet, and the part_number requirement clarifies its 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 explicitly guides usage: section mode default with summary first, search mode for targeted questions, and a detailed 'Datasheet vs Reference Manual' section explaining when to use this tool versus consulting a reference manual. It also maps status values to next actions (prefetch_datasheets, check_extraction_status, request_datasheet_upload), providing unambiguous when-to-use versus alternative tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_datasheet_uploadAInspectRequest a signed URL to upload a datasheet PDF for a component whose datasheet we don't have. Use this when search_parts / get_part_details / prefetch_datasheets return datasheet_status='no_source' (and a retry didn't help) or 'unsupported'. Free — the upload fee is only charged on confirm_datasheet_upload after we validate the file.
Flow (3 steps):
Call request_datasheet_upload with the MPN, the file's SHA-256, and its byte size. You get back an upload_url, upload_method ('PUT'), upload_headers, and an opaque upload_token.
Upload the PDF directly to the returned URL with curl: curl -X PUT -H 'Content-Type: application/pdf' --data-binary @file.pdf "$UPLOAD_URL" (add any headers from upload_headers).
Call confirm_datasheet_upload with the upload_token. Server verifies the bytes, re-hashes, checks for the MPN on the first page, charges the upload fee (50¢), and queues extraction. Returns document_id + status='pending'.
Validation rules (checked at confirm time, refunded on failure):
File must be a valid PDF (magic bytes + parseable).
Actual SHA-256 must match expected_sha256.
Actual byte size must match size_bytes (±0).
MPN or its core stem must appear in the first page text (catches wrong-file uploads). Scanned image-only PDFs will fail this check — upload a text-based PDF.
Max 50MB per file. No dev-kit manuals / BOB schematics / app-notes as datasheets — use the matching MPN's actual datasheet.
Uploaded datasheets are scoped to your organization (private). They satisfy read_datasheet, search_datasheets, check_design_fit, and analyze_image for your org's tokens only.
Tokens expire after 15 minutes. If upload fails or times out, just call request_datasheet_upload again.
| Name | Required | Description | Default |
|---|---|---|---|
| size_bytes | Yes | Size of the PDF in bytes. Must be ≤ 50_000_000 (50MB) and > 1024. | |
| part_number | Yes | Manufacturer part number the PDF belongs to. Must be a real MPN, not a value or description. | |
| manufacturer | No | Optional. Manufacturer name (e.g. 'Texas Instruments') if the MPN alone doesn't disambiguate. | |
| expected_sha256 | Yes | Lowercase hex SHA-256 of the PDF bytes (64 chars). Used both as the storage key (content-addressed) and to detect tampering. Compute with `shasum -a 256 file.pdf`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) by disclosing token expiry (15 minutes), validation rules and refunds, fee timing (only on confirm), org scoping/privacy, and the exact upload method (PUT with headers). It also explains that uploaded datasheets satisfy other tools' queries. This is rich, honest behavioral context with no contradiction.
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?
Despite being long, the description is tightly structured: purpose sentence, trigger conditions, numbered 3-step flow, validation rules, scoping note, and expiry/retry note. Each sentence carries useful information and the structure mirrors the actual workflow. It is front-loaded with the core purpose and then organized logically, earning 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?
With no output schema, the description must explain return values, and it does: upload_url, upload_method ('PUT'), upload_headers, upload_token. It also covers the full end-to-end process, validation rules, fee, privacy, expiration, and next step (confirm_datasheet_upload). For a tool with 4 params and a multi-step flow, this is complete guidance.
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 flow context (e.g., 'You get back an upload_url...') and validation rules that reference parameters (e.g., MPN on first page), but it does not significantly extend the parameter meanings already provided in the schema. The schema already explains expected_sha256 as content-addressed and tamper-detecting, and size_bytes limits. No new parameter semantics are introduced.
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+resource: 'Request a signed URL to upload a datasheet PDF for a component whose datasheet we don't have.' It clearly distinguishes from siblings by naming the exact trigger conditions (datasheet_status='no_source' or 'unsupported') and contrasts with confirm_datasheet_upload. This is a precise, differentiated purpose statement.
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 states when to use the tool: 'Use this when search_parts / get_part_details / prefetch_datasheets return datasheet_status="no_source" (and a retry didn't help) or "unsupported".' It also provides exclusion guidance (no dev-kit manuals, BOB schematics, app-notes) and a step-by-step flow that clarifies the tool's role versus confirm_datasheet_upload. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_datasheetsASemantic search across all extracted datasheets. Finds components matching natural language queries about specifications, features, or capabilities. Best for broad spec-based discovery across all parts (e.g. 'low-noise LDO with PSRR above 70dB'). Only searches datasheets that have been previously extracted — not all parts that exist. For finding specific parts by number, use search_parts instead.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 15) | |
| query | Yes | Natural language search query | |
| section_type | No | Optional: limit search to a specific section type | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the baseline is covered. The description adds important behavioral context beyond annotations: the tool is limited to previously extracted datasheets, and it performs semantic (natural language) matching rather than exact keyword search. This helps the agent understand scope and result variability. No contradictions 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?
Four sentences, all purposeful. The first sentence states the core function, the second expands on query types, the third gives usage context with an example, and the fourth provides a caveat and alternative. No redundancy, front-loaded, 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?
For a straightforward search tool with comprehensive annotations and schema, the description covers the key aspects: what it searches, the extraction-status limitation, and the differentiation from search_parts. It does not mention the optional 'section_type' parameter, but the schema already fully documents that parameter. Given no output schema, the description is sufficiently complete for an agent to decide when and how to invoke it.
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%, so baseline is 3. The description adds value by clarifying what the 'query' parameter expects: natural language about specifications, features, or capabilities, with an example ('low-noise LDO with PSRR above 70dB'). It does not repeat parameter descriptions from the schema but provides richer guidance on how to phrase queries.
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+resource: 'Semantic search across all extracted datasheets.' It clearly states the tool finds components matching natural language queries about specifications, features, or capabilities. It also distinguishes from siblings by explicitly directing users to 'search_parts' for part-number lookups.
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 provides explicit when-to-use guidance: 'Best for broad spec-based discovery across all parts' and gives a concrete example. It also includes a clear exclusion and alternative: 'Only searches datasheets that have been previously extracted — not all parts that exist. For finding specific parts by number, use search_parts instead.' This fully covers usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_partsASearch for electronic components by part number, description, or keyword. Start here — this is the best entry point for finding components. Queries all configured providers in parallel. Results are merged by MPN with indicative pricing and stock from each source. Each result includes datasheet_status so you know which parts have datasheets available for read_datasheet. Best with specific part numbers or keywords (e.g. 'STM32F103', 'buck converter 3A'). For spec-based discovery in natural language, use search_datasheets instead. When the calling org has a private parts library, matching org-uploaded parts are appended to the results with source='private_library' and any tags the team has applied — including private parts whose MPN, manufacturer, description, type, category, or tag matches the query.
DATASHEET STATUS VALUES:
'ready' — extracted and indexed; call read_datasheet, search_datasheets, or analyze_image.
'extracting' / 'in_progress' / 'queued' / 'pending' — extraction running or scheduled. Poll check_extraction_status every 5-10s until 'ready' or 'failed'. Typical time: 30s-2min.
'not_extracted' — known part but datasheet hasn't been fetched yet. Trigger it via prefetch_datasheets (cheapest) or by calling read_datasheet (auto-triggers on first read).
'no_source' — we couldn't find a public datasheet URL for this MPN. First, retry prefetch_datasheets in 10-30s (the URL resolver re-runs and often finds a source on the second pass). If still 'no_source', the agent can upload the PDF manually via request_datasheet_upload + confirm_datasheet_upload (see those tools). Org-uploaded datasheets are private to the org.
'unsupported' — PDF exists but can't be extracted (scanned image-only, encrypted, or corrupted). Upload a clean text-based PDF via request_datasheet_upload to override.
'failed' / 'error' — extraction errored. The response includes the error reason. Retry via prefetch_datasheets or escalate to support.
'rejected' — input wasn't a real MPN (bare value like '100nF', description, or reference designator). Fix the input and re-call.
'deduplicated' — another part in the family already has this datasheet; same content is returned under the primary MPN.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results per provider (default 20). With providers='all', total results can be up to 3× this value (one set per provider). | |
| query | Yes | Search query (part number or keyword) | |
| providers | No | Which providers to query: 'all' (default), 'jlcpcb', 'mouser', or 'digikey' | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds substantial behavioral context: queries providers in parallel, merges results by MPN, includes private library behavior, and details all datasheet_status values with retry/fallback actions. This goes far beyond annotations without contradiction.
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 long but structured with a clear opening, parameter context, and a detailed datasheet_status breakdown. Every section is purposeful; the length is justified by the need to explain eight status values. Not overly verbose for the complexity.
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?
No output schema exists, but the description fully covers return behavior (merged results, pricing/stock, datasheet_status), provider options, private library augmentation, and related tools for further actions. Complete for a search tool with rich edge cases.
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%, so baseline is 3. The description adds value with example queries ('STM32F103', 'buck converter 3A') and clarifies the results-merge behavior tied to providers/limit, though the schema already covers the 3× limit detail. Slight extra enrichment for parameter use.
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 searches for electronic components by part number, description, or keyword, and identifies it as the best entry point. It explicitly distinguishes from sibling search_datasheets by directing spec-based natural language discovery there.
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?
Provides explicit guidance: 'Start here — this is the best entry point' and 'For spec-based discovery in natural language, use search_datasheets instead.' Also explains when to use prefetch_datasheets or read_datasheet based on datasheet_status, giving clear when-to vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.