What can you do with this server?

A read-only MCP server for finding, comparing, and shortlisting engineering parts from distributor and marketplace APIs (Mouser, DigiKey, AliExpress). * Search for parts: Search across suppliers using keywords, visual hints, and constraints (max price, MOQ, RoHS compliance, in-stock only, shipping days, marketplace results, must-have/must-not-have terms). * Extract visual part hints: Normalize image-recognition observations (pin count, pitch, connector family, package shape, visible text, motor specs, dimensions, board context) into structured, searchable part hints. * Look up a specific part: Retrieve details for a known manufacturer or supplier part number (with auto-detect or explicit PN type). * Compare parts: Side-by-side comparison of 2–10 part numbers or candidates, optionally focused on specific criteria. * Suggest alternate parts: Recommend alternatives when a part is out of stock, obsolete, too costly, has a long lead time, or needs a second source. * Enrich a BOM: Augment Bill of Materials rows with supplier availability, pricing, and sourcing caveats across selected suppliers. * Advanced query processing: Automatically expand and normalize queries, including Korean/field-specific terms and rough OCR text. * Cross-supplier candidate management: Rank, deduplicate, and filter candidates from multiple suppliers with confidence scores and verification checklists. * Caching & rate limit management: In-memory caching reduces repeated API calls; supplier-specific rate limits are respected to prevent overuse.

Which integrations are available for this server?

Allows searching for engineering parts from the AliExpress marketplace (planned integration).

How do I use Parts Finder MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Parts Finder MCP Find a 2.54mm pitch 20-pin shrouded header" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Parts Finder MCP

by controlguy-ys

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Parts Finder MCP

Read-only MCP server for finding, comparing, and shortlisting engineering parts from distributor and marketplace APIs.

Parts Finder is designed for Codex, Claude, and other MCP-capable agents that help engineers identify embedded parts, connectors, cables, motors, sensors, PLC components, and related hardware from rough text or image-derived clues.

The project is MIT licensed. Supplier data remains subject to each provider's API terms.

Status

Implemented:

Mouser Search API keyword search
DigiKey ProductInformation V4 keyword search
AliExpress Open Platform signed read-only marketplace search adapter
in-memory TTL cache for repeated supplier searches
candidate confidence summaries and verification checklists
bounded multi-query expansion from category and visual hints
Korean and field-language query normalization for common part terms
automatic connector/motor hint inference from rough query text
cross-supplier candidate ranking, de-duplication, and constraint filtering
live lookup, comparison, alternate suggestion, and BOM enrichment flows
Image-observation normalization through extract_visual_part_hints
Local rate-limit metadata and guardrails
Codex plugin wrapper and skill
Smoke tests for Mouser, DigiKey, and MCP stdio execution

Planned:

supplier-specific datasheet and lifecycle enrichment
deeper electrical/mechanical parameter extraction from supplier attributes
stronger alternate-part scoring from package, pinout, ratings, and lifecycle data

Related MCP server: swagger-mcp

Process Flow

flowchart TD
  A["Engineer asks for a part or uploads a part photo"] --> B["Codex/Claude extracts visual and text observations"]
  B --> C["MCP tool: extract_visual_part_hints"]
  C --> D["Normalize hints: markings, pin count, pitch, color, keying, board context"]
  D --> E["MCP tool: search_parts"]
  E --> F["Supplier adapters"]
  F --> G["Mouser Search API"]
  F --> H["DigiKey ProductInformation V4"]
  F --> I["AliExpress Open Platform marketplace search"]
  G --> J["Normalize candidates"]
  H --> J
  I --> J
  J --> K["Merge duplicate MPNs across suppliers"]
  K --> M["Score by exact match, visual hints, constraints, stock, price, lifecycle"]
  M --> L["Agent explains likely matches and verification steps"]

Image-Based Search Flow

This MCP server does not process raw images directly. The agent should inspect the image first, then pass structured observations into the MCP tool.

Good visual observations include:

visible text, logos, top markings, labels, and terminal legends
connector pin count, row count, pitch, color, shroud, key slot, latch, and wire count
IC package shape, pin count, board position, nearby crystal/regulator/driver/interface parts
motor diameter, length, shaft type, gearhead, encoder, cable count, and connector type
cable jacket markings, connector gender, locking style, and estimated length
scale clues such as USB ports, 2.54 mm headers, terminal blocks, screws, rulers, or known boards

Example:

{
  "userGoal": "identify black shrouded connector on STM32 development board photo",
  "visibleText": ["3V3", "GND", "RST", "A0", "Mini USB"],
  "packageShape": "black shrouded dual-row box header with key slot",
  "connectorPinCount": 20,
  "connectorRowCount": 2,
  "connectorPitchMm": 2.54,
  "connectorFamily": "IDC box header",
  "connectorMountingStyle": "through hole",
  "boardContext": [
    "STM32 style development board",
    "JTAG or SWD debug/programming connector",
    "2x10 IDC ribbon cable header"
  ]
}

The resulting search should be verified against dimensions, datasheets, pinout, and mating connector before purchasing.

Tools

search_parts: search configured suppliers for engineering part candidates.
extract_visual_part_hints: turn image-recognition observations into searchable part hints.
lookup_part: look up a known manufacturer or supplier part number.
compare_parts: compare known candidates.
suggest_alternates: suggest alternate parts with caveats.
enrich_bom: enrich BOM-like rows.

Version 0.1 is read-only. It must not place orders, create carts, call dropshipping/order APIs, or mutate supplier accounts.

Search Quality Behavior

The MCP now improves rough searches before returning results:

builds up to four bounded query variants from the original query, category hint, visual hints, and exact-looking part numbers
normalizes common Korean/field terms such as 2핀, 커넥터, 패널마운트, 방수, 기어모터, 엔코더, 단자대, 푸시인, and PLC 입출력 모듈 into supplier-friendly English search terms
normalizes common passive, power, and semiconductor field terms such as 저항, 콘덴서, 인덕터, LDO, DC-DC, MOSFET, 다이오드, 10 키로 옴, 100 나노 패럿, and package sizes like 0603
prioritizes supplier-friendly normalized queries when field-language input was translated, while still preserving the original query for traceability
adds compact supplier queries from inferred visual hints, such as connector family, pin count, pitch, gender, and mounting style
runs up to two relaxed fallback queries only when the initial ranked result set is empty, limiting extra API calls while improving recovery from over-specific searches
joins split OCR-like part-number tokens such as STM32 C552 RET6 into exact supplier queries like STM32C552RET6
uses visible OCR text from images as search queries and ranking evidence, including joined top-marking part numbers
uses motor image hints such as shaft diameter, body diameter, body length, encoder, gearhead, and connector type in search expansion and ranking
uses general package dimensions such as length, width, and height in visual search expansion, ranking evidence, and verification checklists
scores candidates against those normalized terms too, so field-language searches can match English supplier descriptions more reliably
infers pin count, row count, pitch, connector family, mounting style, color, wire count, and motor encoder/gearhead hints from rough query text
returns per-candidate confidence, fitSummary, and verificationChecklist fields to make sourcing decisions easier to audit
ranks exact manufacturer or supplier part-number matches above loose keyword matches
merges duplicate candidates that share the same normalized manufacturer part number
filters hard constraints such as manufacturer, required terms, forbidden terms, max unit price, max MOQ, RoHS, and stock
extracts supplier attributes/parameters into normalized specs when available
boosts useful sourcing evidence such as stock, datasheet, product URL, pricing, visual-hint matches, pin count, row count, pitch, mounting style, and connector family
lowers confidence for obsolete/discontinued lifecycle text and marketplace results unless marketplace use is explicitly allowed

The same ranked search foundation powers lookup_part, compare_parts, suggest_alternates, and enrich_bom.

Requirements

Node.js 20 or newer
npm
API credentials for any supplier you want to enable

Install

npm install
npm run build

Run Locally

npm run dev

For built stdio execution:

npm run build
npm start

Without API keys, the MCP server still starts and reports skipped-supplier status. This lets Codex, Claude, or MCP Inspector validate tool wiring before credentials exist.

Environment Setup

Copy .env.example to .env.

cp .env.example .env

On Windows PowerShell:

Copy-Item .env.example .env

Never commit .env. Keep all supplier secrets local.

Common Settings

PARTS_FINDER_LOG_LEVEL=info
PARTS_FINDER_CACHE_DIR=.cache/parts-finder
PARTS_FINDER_CACHE_TTL_SECONDS=300
PARTS_FINDER_DEFAULT_COUNTRY=US
PARTS_FINDER_DEFAULT_LANGUAGE=en
PARTS_FINDER_DEFAULT_CURRENCY=USD

PARTS_FINDER_CACHE_TTL_SECONDS controls the in-memory supplier search cache. The cache reduces repeated API calls across expanded queries, lookup_part, compare_parts, and BOM enrichment while the MCP server process is running. Set it to 0 to disable caching. PARTS_FINDER_CACHE_DIR is reserved for future persistent cache support.

Mouser

Required:

MOUSER_SEARCH_API_KEY=
MOUSER_API_BASE_URL=https://api.mouser.com

Optional local guardrails:

MOUSER_RATE_LIMIT_PER_MINUTE=30
MOUSER_RATE_LIMIT_PER_DAY=1000

Get a Mouser Search API key from the Mouser API Hub. The current adapter uses keyword search and normalizes returned candidates into the MCP part schema.

DigiKey

Required:

DIGIKEY_CLIENT_ID=
DIGIKEY_CLIENT_SECRET=
DIGIKEY_LOCALE_SITE=US
DIGIKEY_LOCALE_LANGUAGE=en
DIGIKEY_LOCALE_CURRENCY=USD
DIGIKEY_CUSTOMER_ID=0

Production:

DIGIKEY_SANDBOX=false
DIGIKEY_API_BASE_URL=https://api.digikey.com
DIGIKEY_TOKEN_URL=https://api.digikey.com/v1/oauth2/token

Sandbox:

DIGIKEY_SANDBOX=true
DIGIKEY_SANDBOX_API_BASE_URL=https://sandbox-api.digikey.com
DIGIKEY_TOKEN_URL=https://sandbox-api.digikey.com/v1/oauth2/token

Important DigiKey notes:

ProductInformation V4 uses OAuth 2.0 client credentials for this MCP use case.
The app must be authorized for ProductInformation V4 in the same environment as the token endpoint.
Production credentials work with api.digikey.com; sandbox credentials work with sandbox-api.digikey.com.
If the token endpoint returns 401 Invalid clientId, the Client ID is invalid for that endpoint/environment.
If OAuth succeeds but product search returns 403, the app is likely not authorized or subscribed to the requested ProductInformation API.
The DigiKey portal may ask for an OAuth callback URL. For this client-credentials flow it is not used at runtime; https://localhost is acceptable as a placeholder if the field is required.

Optional local guardrails:

DIGIKEY_PRODUCT_INFORMATION_RATE_LIMIT_PER_MINUTE=120
DIGIKEY_PRODUCT_INFORMATION_RATE_LIMIT_PER_DAY=1000

AliExpress

AliExpress support is read-only and only participates in search_parts when constraints.marketplaceAllowed is true. This prevents marketplace listings from silently mixing into production distributor recommendations.

The Open Platform exposes different product-search APIs depending on app approval and product line. Set ALIEXPRESS_PRODUCT_SEARCH_PATH to the search API path granted to your app. The default is a dropshipping-style text search path.

ALIEXPRESS_APP_KEY=
ALIEXPRESS_APP_SECRET=
ALIEXPRESS_ACCESS_TOKEN=
ALIEXPRESS_REFRESH_TOKEN=
ALIEXPRESS_API_BASE_URL=https://api-sg.aliexpress.com
ALIEXPRESS_PRODUCT_SEARCH_PATH=/aliexpress/ds/textsearch
ALIEXPRESS_OAUTH_AUTHORIZE_URL=https://api-sg.aliexpress.com/oauth/authorize
ALIEXPRESS_TOKEN_CREATE_PATH=/auth/token/security/create
ALIEXPRESS_TOKEN_REFRESH_PATH=/auth/token/refresh
ALIEXPRESS_COUNTRY=US
ALIEXPRESS_CURRENCY=USD
ALIEXPRESS_LANGUAGE=en_US
ALIEXPRESS_RATE_LIMIT_PER_SECOND=
ALIEXPRESS_RATE_LIMIT_PER_DAY=

AliExpress rate limits vary by app key, API, and app-key/API combination. Copy the approved quotas from the Open Platform console after the app is reviewed.

Marketplace caveat: AliExpress results should be treated as prototyping or long-tail sourcing leads unless the exact seller, variant, dimensions, authenticity, shipping terms, and ratings are verified.

MCP Configuration

After npm run build, add this server to an MCP-capable client.

{
  "mcpServers": {
    "parts-finder": {
      "command": "node",
      "args": ["C:/absolute/path/to/parts-finder-mcp/dist/index.js"]
    }
  }
}

If the client does not load .env from the project directory, pass environment variables explicitly in the MCP config or launch the client from the project root.

Codex Plugin

The Codex plugin wrapper lives at:

plugins/codex/parts-finder

It contains:

.codex-plugin/plugin.json
.mcp.json
skills/parts-sourcing/SKILL.md

Validate it with:

python C:/Users/googo/.codex/skills/.system/plugin-creator/scripts/validate_plugin.py plugins/codex/parts-finder

The plugin .mcp.json points to the built MCP server:

{
  "mcpServers": {
    "parts-finder": {
      "command": "node",
      "args": ["../../../dist/index.js"],
      "env": {
        "PARTS_FINDER_LOG_LEVEL": "info"
      }
    }
  }
}

Smoke Tests

Build first:

npm run build

Run supplier smoke tests:

npm run smoke:mouser
npm run smoke:digikey

Run MCP stdio smoke tests:

npm run smoke:mcp
npm run smoke:mcp-cache
npm run smoke:mcp-fit-summary
npm run smoke:mcp-digikey
npm run smoke:mcp-aliexpress
npm run smoke:mcp-workflows

DigiKey production override example:

$env:DIGIKEY_SANDBOX='false'
$env:DIGIKEY_TOKEN_URL='https://api.digikey.com/v1/oauth2/token'
npm run smoke:mcp-digikey

Expected successful DigiKey MCP smoke output for a connector query looks like:

Raw count: 1196
Candidates: 2

Rate Limits

The server stores supplier rate-limit metadata so adapters can throttle before calling APIs:

Mouser default: 30/min, 1000/day; verify against current account/API behavior.
DigiKey ProductInformation standard quota: 120/min, 1000/day; honor X-RateLimit-*, X-BurstLimit-*, and Retry-After headers.
AliExpress: app-key/API/API+app-key quotas vary and should be copied from the Open Platform console after approval.

Candidate Verification Checklist

Before recommending a final part, the agent should verify:

exact manufacturer part number
supplier part number
pin count, pitch, rows, gender, keying, latch, and mounting style
voltage, current, temperature, and environmental ratings
stock quantity and lead time
lifecycle status and replacement notice
datasheet or official product-page match
mating connector and crimp terminal compatibility

Image-derived matches should be treated as low confidence until measurements or exact markings confirm them.

Development

npm run build
npm test
npm audit

License

MIT.

Available Tools

6 tools

compare_partsC

Compare two to ten known part numbers or candidates.

ParametersJSON Schema

Name	Required	Description	Default
`parts`	Yes
`criteria`	No

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description must carry the full burden. It states 'compare' which suggests read-only behavior, but does not disclose side effects, permissions, or return value structure. Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely short (one sentence) but lacks necessary details. Concise but under-specified. Not enough structure for effective use.

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

Completeness1/5

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

Given two parameters, no output schema, and no annotations, the description is severely incomplete. It omits what 'compare' returns, how 'criteria' is used, and any usage context.

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

Parameters1/5

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

Schema description coverage is 0% and the description does not explain any parameters. 'parts' and 'criteria' are undefined. The description adds no meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb 'compare' and resource 'part numbers or candidates' are clear. It specifies a numeric range (2-10). However, it does not explain what 'compare' entails (e.g., output similarities, differences), so it's slightly vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings like 'search_parts' or 'suggest_alternates'. The description implies comparing multiple parts but does not specify context or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

enrich_bomB

Enrich BOM-like rows with supplier availability, pricing, and sourcing caveats.

ParametersJSON Schema

Name	Required	Description	Default
`items`	Yes
`suppliers`	No
`pricingQuantity`	No

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It states it enriches with data but does not disclose whether it modifies the input, returns enriched data, or any side effects. No mention of authentication, rate limits, or what happens with missing parts.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of 11 words, very concise. It avoids redundancy. However, it is so brief that critical details are omitted, balancing conciseness against completeness. For a 3-param tool, it could be slightly expanded without losing conciseness.

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

Completeness2/5

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

Given the tool's complexity (nested array input, optional suppliers list, no output schema), the description is severely incomplete. It provides no information about return values, error handling, or parameter constraints. An AI agent would lack guidance on how to use the tool correctly.

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

Parameters1/5

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

Schema description coverage is 0%, yet the description adds no meaning to the parameters. It does not explain 'items', 'suppliers', or 'pricingQuantity'. The schema provides basic structure, but the description fails to clarify expected input format, defaults, or constraints beyond what schema implies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: enrich BOM-like rows with supplier availability, pricing, and sourcing caveats. The verb 'enrich' and resource 'BOM-like rows' are specific, and the enrichments are listed. It distinguishes from siblings like 'lookup_part' (single part lookup) and 'compare_parts' (comparison) by focusing on batch enrichment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you have a list of parts needing supplier data, but no explicit guidance on when to use this over alternatives like 'lookup_part' or 'suggest_alternates'. No when-not-to-use or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

extract_visual_part_hintsC

Normalize image-recognition observations into searchable part hints. The MCP server does not process raw images; pass observations from Codex/Claude vision.

ParametersJSON Schema

Name	Required	Description	Default
`color`	No
`notes`	No
`pinCount`	No
`userGoal`	No
`pinLayout`	No
`confidence`	No
`motorHints`	No
`visibleText`	No
`boardContext`	No
`dimensionsMm`	No
`imageQuality`	No
`packageShape`	No
`cableWireCount`	No
`connectorPitchMm`	No
`connectorPinCount`	No

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; the description only mentions that raw images are not processed, but fails to disclose behavioral traits such as side effects, rate limits, or output format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two front-loaded sentences, each earning its place by clarifying purpose and constraints, though it sacrifices parameter details.

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

Completeness1/5

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

Given 15 parameters, nested objects, no output schema, and no annotations, the description is severely incomplete, lacking return value info and parameter guidance.

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

Parameters1/5

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

With 0% schema description coverage and no parameter explanations in the description, the AI agent receives no additional meaning beyond parameter names, which is insufficient for a tool with 15 complex parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool normalizes image-recognition observations into searchable part hints, distinguishing it from siblings like search_parts (text-based) 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.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by requiring observations from Codex/Claude vision, but does not explicitly specify when to use this tool versus alternatives, nor does it list exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_partC

Look up a known manufacturer or supplier part number.

ParametersJSON Schema

Name	Required	Default
`kind`	No	auto
`supplier`	No
`partNumber`	Yes

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description bears full responsibility for behavioral disclosure. It does not address read-only nature, authentication requirements, rate limits, or error handling (e.g., part not found).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but lacking essential detail. It is front-loaded but fails to earn its place by omitting crucial information.

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

Completeness2/5

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

No output schema is provided, and the description does not specify what information is returned (e.g., specs, pricing, availability). For a lookup tool, this is a significant gap.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not explain any of the three parameters (partNumber, kind, supplier). The mention of 'manufacturer or supplier' is ambiguous and does not clarify the 'kind' enum or 'supplier' field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action (look up) and resource (manufacturer or supplier part number). It is specific but does not differentiate from sibling tools like search_parts, which may have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as search_parts or suggest_alternates. The description lacks any context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_partsC

Search configured distributor and marketplace suppliers for engineering part candidates.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes
`suppliers`	No
`constraints`	No
`visualHints`	No
`categoryHint`	No

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description must disclose behavioral traits. It does not mention result format, pagination, error handling, or side effects. The description is too minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (one sentence) but lacks necessary detail. While concise, it sacrifices informativeness. It is not front-loaded with critical guidance.

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

Completeness1/5

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

Given the complexity (6 parameters, nested objects, no output schema), the description is severely incomplete. It fails to explain return values, parameter semantics, or behavioral context. Essential information is missing.

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

Parameters1/5

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

Schema description coverage is 0%, yet the description provides zero explanation of any of the 6 parameters, including nested objects like constraints and visualHints. The agent has no guidance on parameter usage beyond schema names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches for engineering parts across configured distributor and marketplace suppliers, which is a specific verb+resource. It differentiates from sibling tools like lookup_part or suggest_alternates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. Sibling tools exist but are not mentioned. The description lacks context on prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

suggest_alternatesB

Suggest alternate parts for unavailable, costly, obsolete, or second-source needs.

ParametersJSON Schema

Name	Required	Default
`reason`	No	unknown
`mustMatch`	No
`partNumber`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. However, it only says 'suggest', which implies a read-only operation, but does not confirm lack of side effects, rate limits, or other critical behaviors for a mutation-free tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the action and efficiently conveys core purpose without unnecessary words.

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

Completeness2/5

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

With 3 parameters, no output schema, and no annotations, the description is too brief. It omits return value expectations, parameter details, and behavioral context, leaving the agent with significant gaps.

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

Parameters1/5

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

Schema description coverage is 0%, meaning the description adds no explanation for the 3 parameters. Although 'reason' enum overlaps with listed contexts, the description does not explicitly map to the parameter, and 'mustMatch' is entirely unmentioned.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('suggest alternate parts') and the specific contexts (unavailable, costly, obsolete, second-source), making the purpose distinct from sibling tools like compare_parts or search_parts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool by listing triggering conditions (unavailable, costly, etc.), but does not explicitly state when not to use it or compare it to alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: searching, looking up, comparing, suggesting alternatives, enriching BOM data, and extracting visual hints. No two tools perform the same function.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., search_parts, lookup_part), making the naming predictable and easy to understand.

Tool Count5/5

Six tools cover the core operations of a parts finder without being excessive. Each tool justifies its existence, and the set feels well-scoped for the domain.

Completeness5/5

The tool surface covers the essential workflows: discovery (search, visual hints), identification (lookup), comparison (compare, suggest alternates), and enrichment (enrich BOM). No obvious gaps for typical part-finding tasks.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

apis-io B
io.apis
Read-only MCP server over the APIs.io catalog — discover APIs, providers, tags & artifacts.
Search Developer Tools Documentation Access
1332
PartsTable A
com.partstable
MCP server for IT hardware parts research: normalize PNs, search listings, get subs/comps.
Search E-commerce & Retail Research & Data
52
kalicart-global A
io.github.giuseppesocci-bot
Federated commerce search across independent WooCommerce merchants. Keyless, read-only MCP server.
E-commerce & Retail Search
53
FarmNeural Public API
com.farmneural
Public, read-only MCP server for FarmNeural company facts, packages, and capabilities.
Documentation Access Developer Tools
1

Related MCP Servers

jlcpcb-mcp
Search E-commerce & Retail
Eyalm321
A
license
A
quality
C
maintenance
MCP server for JLCPCB/LCSC component search, live stock and pricing, datasheets, and PCB/3D printing ordering via authenticated API.
Updated 3 months ago (2026-06-03 22:46 UTC)
28
1
MIT
swagger-mcp
Documentation Access Developer Tools
emreycolakoglu
A
license
A
quality
B
maintenance
A read-only MCP server for navigating OpenAPI / Swagger specifications, enabling agents to search endpoints, retrieve parameters and schemas, and inspect authentication without loading the full spec into context.
Updated 2 months ago (2026-07-08 19:20 UTC)
9
19
MIT
digikey-mcp
Search Research & Data Developer Tools
itsyashk
A
license
A
quality
B
maintenance
A read-only MCP server for electronics engineers to search DigiKey parts, get detailed product information, plan and validate BOMs, and export order lists, using the official DigiKey API.
Updated 2 months ago (2026-07-10 21:15 UTC)
7
Apache 2.0
OWASP Pentest Guide Knowledge
Penetration Testing Documentation Access Search
sunick2009
A
license
A
quality
B
maintenance
Read-only MCP server for precise lookup, search, and versioned retrieval of OWASP testing guides (WSTG, MASTG, ISTG, AITG) with full provenance on every result.
Updated 2 months ago (2026-07-18 07:52 UTC)
11
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/controlguy-ys/electronic-parts-finder-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server