sheetsdata-mcp
Server Details
Electronic component datasheets for AI agents — specs, pinouts, package data on demand.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- octoco-ltd/sheetsdata-mcp
- GitHub Stars
- 6
- Server Listing
- SheetsData MCP
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.
Tool Definition Quality
Average 4.7/5 across 12 of 12 tools scored.
Tools have mostly distinct purposes, but search_parts and search_datasheets could be confused since both are search functions. Descriptions help differentiate (keyword vs semantic), but the overlap is slight.
All tool names follow a consistent verb_noun snake_case pattern (e.g., analyze_image, check_design_fit, search_parts). No mixing of styles or irregularities.
12 tools is well-scoped for a datasheet server. Covers searching, details, comparison, alternatives, reading, image analysis, design fit, status checking, prefetching, and uploads without excess.
The tool set covers the full workflow from discovery to design validation and handling missing datasheets. No obvious gaps for the intended domain of electronic component datasheets.
Available Tools
12 toolsanalyze_imageARead-onlyIdempotentInspect
Analyze 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context about the types of images handled (graphs, drawings, diagrams) and that it supplements text extraction, but does not contradict annotations. It could mention nondestructive behavior explicitly, but not necessary given 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 concise and well-structured: purpose sentence, usage guidance, important note, and examples. No extraneous text; every sentence adds value. Front-loaded with key information.
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 description covers primary usage scenarios and constraints. With no output schema, it doesn't specify return format, but examples imply output types. Could be slightly more complete by stating output is a text description or structured data, but adequate given simplicity.
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%, describing all three parameters. The description adds meaning: explains image_key is from read_datasheet, question is optional to focus analysis, and part_number is the MPN. Examples demonstrate usage, fully compensating for any lack in 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's purpose: analyzing an image from a datasheet using vision AI. It specifies the resource (image) and action (analyze), and distinguishes it from sibling tools like read_datasheet by focusing on visual data extraction. Examples further clarify.
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 this tool (when read_datasheet returns an image section) and when to prefer alternatives (prefer read_datasheet for precise numeric values). It provides explicit context for usage with examples, aiding correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_design_fitARead-onlyInspect
Validate 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false) are consistent. Description adds behavioral context: two-tier validation (structured vs LLM), extraction triggering with polling, temperature honesty (junction estimation with assumptions), and detailed result semantics. 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?
The description is long but well-structured with sections (Parameter mapping, Result semantics, Temperature honesty, Behavior, When NOT to use) and an example. Front-loaded with main purpose. Slightly verbose but every section adds value.
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, but description thoroughly covers return values (PASS/FAIL/WARNING/INSUFFICIENT_DATA) and fields like limit_type, validation_method, temperature_basis. Addresses complexity: 7 params, variable component types, temperature estimation, extraction delays, and fallback behavior.
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. Description adds significant value: parameter mapping by component type (e.g., supply_voltage=VDS for MOSFETs), explains ambient_temp handling, and gives examples. Exceeds the baseline.
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 validates component fit within operating conditions against datasheet limits. It uses a specific verb ('Validate') and resource ('component design fit'), and distinguishes from siblings like analyze_image (for SOA curves) and read_datasheet (for data retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (checking nameplate limits) and when not to use (e.g., need SOA curves or passive parts), with specific alternatives (use analyze_image, read_datasheet). Provides context for temperature estimation and extraction delays.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_extraction_statusARead-onlyIdempotentInspect
Check 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds significant value: states the tool is free, details each status value with actionable guidance, and specifies output content (extraction step, elapsed seconds, document ID). 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-structured with sections for usage and status values. It is front-loaded with the main purpose. While somewhat verbose, every sentence adds necessary information, making it efficient 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?
Given the complexity of extraction statuses and no output schema, the description is comprehensive: it explains each status value, recommended follow-ups, and what the output contains. It covers all important aspects for an agent to use 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%: the part_numbers parameter has a description. The tool description reinforces and adds context: '1-20 MPNs', 'Must be specific manufacturer part numbers, not values or descriptions.' This clarifies the parameter semantics 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's purpose: 'Check the extraction status of one or more parts' with a specific verb and resource. It distinguishes from siblings like read_datasheet and prefetch_datasheets by explicitly stating when to use it ('Use after prefetch_datasheets or after read_datasheet triggers a new 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?
Provides explicit usage context: polling cadence every 5-10 seconds, stopping conditions, and alternatives for different statuses (e.g., retry prefetch_datasheets for 'no_source', escalate for 'failed'). Also advises against polling faster than 5 seconds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_partsARead-onlyIdempotentInspect
Compare 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive. Description adds: uses only cached datasheets, upfront validation, rejection behavior, per-part error handling, and detailed datasheet status meanings.
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?
Well-structured with sections, but long. Front-loaded with key purpose and usage. Could be slightly trimmed but overall good.
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 no output schema, description fully covers all behaviors, states, and error modes. No gaps for correct agent selection.
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 part_numbers with all constraints (2-5, string). Description adds examples, what not to pass, and the rejection consequence, going beyond 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 it compares 2-5 components side by side with merged provider data and datasheet info. It distinguishes from siblings like get_part_details and search_parts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using instead of looping get_part_details, and for discovery use search_parts or find_alternative. Also warns about rejection for non-MPNs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
confirm_datasheet_uploadADestructiveInspect
Confirm 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behaviors beyond annotations: charges a 50¢ fee, creates private records, queues extraction, has 15-minute token expiry. Details failure modes and their financial impact (no charge for invalid_pdf). Annotations indicate destructive and open-world, which align with description.
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?
Well-structured with bullet points for success and failure modes. Slightly lengthy but every element adds value. Front-loaded with purpose and required parameter.
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?
Comprehensive for a multi-step mutation tool: explains entire flow, success response fields, typical extraction time, and all failure modes with causes and consequences. No output schema but description covers return values adequately.
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?
Only one parameter (upload_token) with 100% schema coverage describing it as opaque token. Description adds instruction to pass token from request step, but schema already covers the meaning. Baseline 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 confirms a datasheet upload started via request_datasheet_upload. It specifies the action (confirm) and resource (upload), distinguishing it from siblings like request_datasheet_upload and check_extraction_status.
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: after request_datasheet_upload, passing the upload_token. Lists failure modes with actionable guidance (e.g., retry, re-compute hash, re-request). Refers to sibling check_extraction_status for next step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_alternativeARead-onlyIdempotentInspect
Find 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safety (readOnlyHint, idempotentHint, non-destructive). The description adds significant behavioral details: filters out eval boards, fuzzy package matching, fallback to semantic search, and the hint field. 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?
Well-structured with sections for usage, behavior, example, and datasheet status. The datasheet status section is lengthy but relevant to tool behavior. Could be slightly more concise, but front-loaded with key info.
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?
Completes the picture by explaining return fields (match_score, match_notes, hint) and linking to sibling tools. No output schema, but description covers expected response sufficiently 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 clear descriptions. The description adds extra context: explains constraint options ('in_stock', 'same_package', 'jlcpcb') with details on fuzzy matching and JLCPCB scope, plus an example. Slightly above baseline 3.
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 purpose: 'Find alternative / second-source components for a given MPN.' It specifies ranking by match and distinguishes from siblings like search_parts and compare_parts.
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 provides 'When to use' and 'When NOT to use' sections, listing specific scenarios and naming alternative tools (search_parts, compare_parts), offering clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_part_detailsARead-onlyInspect
Get 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and non-destructive. Description adds that prefetch_datasheet triggers background extraction with 'no extra charge', and exhaustively documents all datasheet status values with recommended actions. 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?
The description is structured with clear sections: core purpose, usage warnings, and detailed datasheet status values. It is front-loaded and every sentence adds value, though the status list is lengthy but necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return content (specs, pricing, stock, datasheet summary) and covers datasheet status thoroughly. It addresses edge cases like failed extraction. Could be more specific about pricing structure.
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% for all three parameters. The description adds real-world examples for part_number, clarifies the effect of prefetch_datasheet, and provides context for the provider enum 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 it gets full details for a specific component, returning specs, pricing, and stock. It distinguishes from siblings like search_parts by positioning as a drill-down after 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?
Explicitly advises 'Use after search_parts' and provides precise examples of valid MPN/LCSC numbers, while warning against passing values, descriptions, or designators. Does not specify situations to avoid, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
prefetch_datasheetsARead-onlyInspect
Trigger 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses non-blocking behavior, retry logic, and detailed status meanings. However, the annotations include readOnlyHint=true, while the tool triggers a background extraction (a side effect). This is a minor contradiction; the description is transparent about the trigger, so the score is slightly reduced.
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 relatively long but well-organized, with a clear front-loaded goal followed by actionable status details. Every sentence serves a purpose (e.g., retry guidance, input rules, status table). Some redundancy could be trimmed, but overall it is efficient given 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?
Given the absence of an output schema, the description fully explains return values with a detailed status table and follow-up actions. It covers all edge cases (no_source, rejected, deduplicated) and cross-references sibling tools. The tool's role in the datasheet workflow is thoroughly contextualized.
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 only parameter 'part_numbers' is fully described in the schema (100% coverage). The description adds significant context: valid input types (MPNs, LCSC numbers), examples, prohibitions (no bare values), and the 20-item limit. This goes well beyond the schema's minimal description.
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 triggers background datasheet extraction for multiple parts, returning immediately. It distinguishes from siblings like read_datasheet and check_extraction_status by specifying it is for prefetching/warming up. The verb+resource is precise and actionable.
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 (warm up BOM before read_datasheet) and when not (bare values, descriptions). Provides alternatives for failed lookups (retry, request_datasheet_upload). Includes a comprehensive status table with recommended actions for each value, making decision criteria clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_datasheetARead-onlyInspect
Read 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important behavioral traits beyond annotations: extraction triggers on first call, caching, fallback from section to search mode, dynamic sections, and detailed status responses. Annotations indicate readOnlyHint=true and destructiveHint=false; description adds context 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 well-structured with headings and lists, but is quite long. However, every section is necessary for a tool with this complexity. Front-loaded with core purpose.
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 all aspects: dual-mode operation, extraction process, status values and actions, part_number rules, and relationship to sibling tools. Despite no output schema, the description sufficiently explains what the tool returns and how to interpret results.
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?
All five parameters have schema descriptions, but the tool description adds significant value: explains the two modes in depth, the dynamic nature of section names, the requirement for part_number to be a specific MPN, and search query necessity.
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 reads from a component's datasheet with two modes (section and search). It distinguishes from sibling tools like search_datasheets and provides specific instructions on usage.
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 guidelines on when to use section vs search mode, how to start with 'summary', handling extraction delays, and differentiation between datasheet and reference manual. Also includes detailed status values and recommended actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_datasheet_uploadAInspect
Request 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`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint: false, destructiveHint: false) imply mutation but not destruction. The description adds key behavioral details: tokens expire after 15 minutes, uploads are scoped to organization, validation rules are explained, and the fee structure is clarified. However, it could mention rate limits or token refresh specifics.
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 with flow steps, bullet-like lists for validation rules, and front-loaded purpose. Every sentence provides value; no redundancy. Length is appropriate for 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?
Despite no output schema, the description fully explains the return values (upload_url, upload_method, upload_headers, upload_token) and the subsequent flow. It also addresses prerequisites, constraints, and edge cases. Complete for this tool's complexity.
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?
Input schema has 100% coverage with descriptions for all parameters. The description adds value by explaining the computed SHA-256 command (`shasum -a 256 file.pdf`) and reinforces constraints like max size and valid MPN. Slight deduction because parameter semantics are mostly covered in 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's purpose: 'Request a signed URL to upload a datasheet PDF for a component whose datasheet we don't have.' It specifies the resource (datasheet PDF) and the action (request upload URL), and distinguishes from siblings like confirm_datasheet_upload.
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 this tool: 'Use this when search_parts / get_part_details / prefetch_datasheets return datasheet_status='no_source'...' It also explains the broader context as part of a 3-step flow, including what happens after and when to retry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_datasheetsARead-onlyIdempotentInspect
Semantic 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 |
Tool Definition Quality
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. The description adds value by specifying the tool only searches extracted datasheets, which aligns with openWorldHint (results may be incomplete). 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?
Three sentences, each serving a distinct purpose: stating the function, giving a usage example with scope, and clarifying limitations with a sibling tool reference. No extraneous words.
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 core functionality, scope limitations, and alternatives. Without an output schema, the description does not need to detail return values. It could mention that results include relevance scores or sections, but the current detail is adequate for an agent to understand usage.
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 parameter descriptions. The description adds context by explaining the query is for 'natural language queries about specifications, features, or capabilities,' and the section_type enum is already well-documented in the schema. The description reinforces but does not repeat schema details.
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 performs 'semantic search across all extracted datasheets' and provides concrete usage examples. It effectively distinguishes itself from the sibling tool 'search_parts' by specifying it is for spec-based discovery rather than part number lookup.
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 'Best for broad spec-based discovery across all parts' and provides a clear exclusion: 'Only searches datasheets that have been previously extracted — not all parts that exist.' It also directs users to 'use search_parts instead' for specific part numbers, offering a precise alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_partsARead-onlyIdempotentInspect
Search 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: parallel provider queries, result merging by MPN, pricing/stock inclusion, and exhaustive explanation of datasheet status values. 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?
The description is well-structured with front-loaded purpose, but the datasheet status values section is lengthy. While detailed and useful, it could be slightly more concise without losing clarity.
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 providers, private library, datasheet states), the description covers all necessary aspects: input, behavior, output characteristics, and integrations with other tools. It is fully self-contained.
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?
With 100% schema coverage, the description still adds value by explaining the limit parameter's interaction with providers and the effect of multiple providers on total results. This goes beyond the schema's basic description.
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 explicitly positions it as the best entry point. It distinguishes from sibling tools like search_datasheets.
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 guidance on when to use this tool ('start here'), what queries work best, and when to use an alternative (search_datasheets for spec-based discovery). It also notes behavior with private libraries.
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.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.