How do I use digi-mouse-search?

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., "@digi-mouse-search compare prices for the part number ESP32-WROOM-32" 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.

de en es ja ko ru zh

digi-mouse-search

by tmpk13

Overview Schema Related Servers Score Discussions

Python

Remote

eparts-search-mcp

An MCP server that searches electronic components across DigiKey, LCSC and Mouser. Each distributor can be queried on its own or all of them together, with offers for the same part number merged into a single entry so prices can be compared.

Tools

Tool	Purpose
`search_parts`	Keyword search across one or several distributors
`part_details`	Look up a single part by manufacturer or distributor part number
`source_status`	Which sources are configured, and how much request budget is left
`clear_cache`	Drop cached responses to force fresh stock and pricing

search_parts takes a sources list. Omitting it searches every configured distributor; passing ["mouser"] searches that one alone. Results are merged by part number by default, with a cheapest_at_quantity comparison; pass merge=false to keep each distributor's results in a separate list.

The comparison only considers offers that have a price at the quantity asked for. LCSC sells many parts in multiples of ten, so at a quantity of one such an offer has no applicable break and is left out of the comparison rather than being counted as free.

If one distributor fails, is unconfigured, or is out of quota, the others still return results and the failure is reported under errors.

Related MCP server: Nexar MCP Server

Installing

To use the server from anywhere on the system, install it as a standalone tool. The executable lands in ~/.local/bin ($XDG_BIN_HOME if set), with its dependencies in their own environment under ~/.local/share/uv/tools:

uv tool install .

mise run install-tool does the same, and mise run uninstall-tool removes it. After installing, eparts-search-mcp runs the server on stdio from any directory, reading credentials from the XDG config file described below. Nothing outside ~/.local and ~/.config is touched, so no privileged install step is needed.

Make sure ~/.local/bin is on PATH:

export PATH="$HOME/.local/bin:$PATH"

Development setup

For working on the server rather than using it:

mise install
mise run install
mise run test

Credentials can come from a config file or the environment. The file keeps them out of the environment and process listings; it is read by default from ~/.config/eparts-search-mcp/config.toml (or $XDG_CONFIG_HOME if set), so no EPARTS_CONFIG is needed:

# ~/.config/eparts-search-mcp/config.toml
[providers.digikey]
# DigiKey: register an app at developer.digikey.com with Product Information enabled
client_id = "..."
client_secret = "..."

[providers.lcsc]
# LCSC: partner credentials issued by an account manager
key = "..."
secret = "..."

[providers.mouser]
# Mouser: request a Search API key from mouser.com/api-hub
api_key = "..."

Because the file holds secrets, keep it readable only by you. The server warns on startup if it is accessible to group or others:

chmod 600 ~/.config/eparts-search-mcp/config.toml

The same values may instead be supplied through the environment, which overrides the file:

export DIGIKEY_CLIENT_ID=...
export DIGIKEY_CLIENT_SECRET=...
export LCSC_KEY=...
export LCSC_SECRET=...
export MOUSER_API_KEY=...

Only the credentials of the distributors you actually want are needed. A source without credentials is reported as unconfigured rather than failing the search.

Getting credentials

DigiKey. A personal developer app only ever gets sandbox access, and the sandbox returns synthetic data. For real stock and pricing you need a Production app, which lives under an Organization:

Sign in at developer.digikey.com with your DigiKey account.
Open Organizations on the nav bar and create one if you are not already a member.
Under Operations, choose Production Apps, then Create Production App.
Enable Product Information for the app.
Open the app to copy its Client ID and Client Secret.

The OAuth callback field is only used by three-legged OAuth. This server uses the two-legged client credentials flow, so the callback is never redirected to; https://localhost satisfies the form.

Sandbox and production credentials are not interchangeable. Sandbox credentials work only against sandbox-api.digikey.com, which is what DIGIKEY_SANDBOX=true selects.

LCSC. The Open API is a partner integration rather than a self-service signup, so credentials come from an LCSC account manager after the calling IP address has been whitelisted. Onboarding starts in a test environment on a separate host (fatapi.lcsc.com) that answers with simulated catalog data; LCSC_SANDBOX=true selects it. Production credentials arrive once the integration is signed off, and are used against api.lcsc.com.

A call is authenticated by a SHA-256 signature over the request parameters, the key, a per request nonce and a timestamp. The secret is an input to that hash and is never transmitted, so it never appears in a URL or a log; the timestamp is checked, meaning a badly wrong system clock reads as an expired request rather than a rejected key.

Mouser. Request a Search API key at mouser.com/api-hub. It is a single key, sent as a query parameter, and arrives by email.

MCP client configuration

Once installed as above, the command is on PATH and needs no path or environment, since credentials come from the config file:

{
  "mcpServers": {
    "eparts-search-mcp": {
      "command": "eparts-search-mcp"
    }
  }
}

Some clients launch servers with a bare environment that does not include ~/.local/bin; give the absolute path there instead:

{
  "mcpServers": {
    "eparts-search-mcp": {
      "command": "/home/you/.local/bin/eparts-search-mcp"
    }
  }
}

To run from a source checkout without installing, or to pass credentials through the client rather than the config file:

{
  "mcpServers": {
    "eparts-search-mcp": {
      "command": "/path/to/eparts-search-mcp/.venv/bin/python",
      "args": ["-m", "eparts_search_mcp"],
      "env": {
        "DIGIKEY_CLIENT_ID": "...",
        "DIGIKEY_CLIENT_SECRET": "...",
        "MOUSER_API_KEY": "..."
      }
    }
  }
}

Rate limits

Each distributor grants roughly a thousand calls per day, so every request is budgeted. Per-second and per-minute windows are enforced by waiting; the daily window is a hard stop that reports an error instead, since a caller cannot usefully wait out a quota that resets at midnight. The daily counter is persisted, so restarting the server does not reset it.

Defaults:

Window	DigiKey	LCSC	Mouser
per second	2	1	1
per minute	60	45	25
per day	1000	1000	1000
burst	5	5	3
max wait	10 s	10 s	10 s

LCSC documents 60 keyword searches per minute and a thousand a day, and counts only calls that succeed. Its per-minute default is set below the documented ceiling, since being throttled by the distributor costs more than waiting locally. When LCSC's own counter rejects a call anyway, the error says so, to distinguish it from the local budget.

Every value is configurable per provider, either by environment variable or by a TOML file. Use none, off, unlimited or 0 to disable a window:

export DIGIKEY_RATE_PER_DAY=250
export DIGIKEY_RATE_PER_MINUTE=30
export LCSC_RATE_PER_MINUTE=20
export MOUSER_RATE_PER_SECOND=none
export MOUSER_RATE_BURST=5
export MOUSER_RATE_MAX_WAIT=30

These also live in the config file (~/.config/eparts-search-mcp/config.toml by default, or wherever EPARTS_CONFIG points), see config.example.toml. Environment variables override the file, so a client launch command can adjust a limit without editing configuration on disk.

Cached responses are served without spending budget. source_status reports what remains for the day.

Other settings

Variable	Default	Meaning
`EPARTS_CONFIG`	`~/.config/eparts-search-mcp/config.toml`	Path to a TOML configuration file; the default location is read when unset
`EPARTS_CACHE_PATH`	`$XDG_STATE_HOME/eparts-search-mcp/cache.sqlite3`	Cache and usage database
`EPARTS_CACHE_TTL`	3600	Cached response lifetime in seconds
`EPARTS_REQUEST_TIMEOUT`	30	HTTP timeout in seconds
`DIGIKEY_SANDBOX`	false	Use the DigiKey sandbox host, which returns synthetic data
`DIGIKEY_LOCALE_SITE`	US	DigiKey site to search
`DIGIKEY_LOCALE_CURRENCY`	USD	Currency for DigiKey pricing
`DIGIKEY_LOCALE_LANGUAGE`	en	Language for DigiKey results
`LCSC_SANDBOX`	false	Use the LCSC test host, which returns simulated data
`LCSC_CURRENCY`	USD	Currency for LCSC pricing: USD, EUR, HKD or CNY
`LCSC_LANGUAGE`	EN	Language for LCSC results: EN or CN

Files on disk

Everything the server keeps lives under the XDG base directories, so an install owns nothing outside the home directory:

What	Where
Executable	`$XDG_BIN_HOME`, i.e. `~/.local/bin/eparts-search-mcp`
Tool environment	`~/.local/share/uv/tools/eparts-search-mcp`
Credentials and settings	`$XDG_CONFIG_HOME/eparts-search-mcp/config.toml`
Cache and daily usage counters	`$XDG_STATE_HOME/eparts-search-mcp/cache.sqlite3`

XDG_CONFIG_HOME and XDG_STATE_HOME default to ~/.config and ~/.local/state when unset. EPARTS_CONFIG and EPARTS_CACHE_PATH override the last two. Uninstalling with uv tool uninstall eparts-search-mcp leaves the config and cache in place; delete those directories to remove them too.

Architecture

classDiagram
    class MCPServer {
        search_parts(keyword, sources, merge)
        part_details(part_number, sources)
        source_status()
        clear_cache(source)
    }
    class SearchService {
        +providers: dict
        +limiters: dict
        +resolve_sources(sources)
        +search(...) SearchResult
        +details(...) list~Part~
    }
    class Provider {
        <<abstract>>
        +name: str
        +configured: bool
        +search(...) list~Part~
        +details(...) Part
        #_cached_request(...)
    }
    class DigiKeyProvider {
        -_token: str
        -_access_token()
        -_manufacturer_filter_id(name)
        -_pick_variation(product)
    }
    class LCSCProvider {
        -_headers(payload)
        -_to_part(entry)
        +sign(payload, key, secret, nonce, timestamp)
    }
    class MouserProvider {
        -_parse_response(response)
        +parse_price(raw)
    }
    class RateLimiter {
        +acquire()
        +remaining_today()
    }
    class Cache {
        +get(key)
        +set(key, provider, value, ttl)
        +get_daily_usage(provider, day)
        +increment_daily_usage(provider, day)
    }
    class Part {
        +source, mpn, manufacturer
        +stock, price_breaks, specs
        +unit_price_at(quantity)
    }
    class MergedPart {
        +mpn
        +offers: list~Part~
        +sources
    }

    MCPServer --> SearchService
    SearchService --> Provider
    SearchService --> RateLimiter
    SearchService --> Cache
    Provider <|-- DigiKeyProvider
    Provider <|-- LCSCProvider
    Provider <|-- MouserProvider
    Provider --> RateLimiter : acquire before call
    Provider --> Cache : read before spending budget
    RateLimiter --> Cache : persist daily counter
    Provider --> Part : produces
    MergedPart o-- Part : groups offers by part number

Request flow for one provider call:

sequenceDiagram
    participant C as MCP client
    participant S as SearchService
    participant P as Provider
    participant K as Cache
    participant L as RateLimiter
    participant A as Distributor API

    C->>S: search_parts(keyword, sources)
    S->>S: resolve_sources
    par each source
        S->>P: search(keyword)
        P->>K: get(key)
        alt cached
            K-->>P: payload
        else not cached
            P->>L: acquire()
            alt budget available
                L-->>P: ok
                P->>A: HTTP request
                A-->>P: response
                P->>K: set(key, payload)
            else daily quota spent
                L--)P: RateLimitExceeded
            end
        end
        P-->>S: parts or error
    end
    S->>S: merge by part number
    S-->>C: results plus per source errors

Notes on the three APIs

DigiKey uses OAuth2 client credentials. The token lasts ten minutes and is cached in memory; requests need the client id header alongside the bearer token. Filters are expressed as opaque ids, so a manufacturer name is first resolved through the manufacturers endpoint.

LCSC signs each request instead of carrying a token: the key, a nonce, a timestamp and the sorted query parameters are hashed with the secret, and the digest travels in a header. Like Mouser it answers with HTTP 200 even when the request failed, putting the real outcome in the body's code field, which the adapter treats as authoritative. There is no per part endpoint, so a details lookup is a keyword search from which the exact match is picked out; a keyword search that returns only near matches yields no result rather than a plausible wrong one. There is no manufacturer filter either, so a manufacturer is folded into the keyword and the results are filtered on the way back.

Mouser uses an API key passed as a query parameter and answers with HTTP 200 even when the request failed, putting the failure in an Errors array. The adapter treats that array as authoritative. Prices arrive as localized display strings rather than numbers.

Parametric specifications have no shared vocabulary between the three distributors, so they are passed through as a name/value map rather than normalized into a common schema. LCSC's reel surcharge is reported the same way, since it is a per order fee that the per unit price ladder cannot express.

Claude Code was used in the making of this tool.

Available Tools

4 tools

clear_cacheA

Drop cached distributor responses to force fresh stock and pricing.

Cached responses do not count against the daily quota, so clearing the cache makes subsequent searches spend real request budget.

ParametersJSON Schema

Name	Required	Description	Default
`source`	No	Clear one source only; omit to clear everything

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses that cached responses are dropped (a destructive action) and that doing so affects the quota of subsequent searches, which is a meaningful behavioral trait. It does not mention undoability, but for a cache clear that is acceptable. No contradictions with annotations exist since none are provided.

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 two concise paragraphs, front-loaded with the primary action and then explaining the quota implication. There is no fluff or redundancy; every sentence earns its place.

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

Completeness5/5

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

Given the tool's low complexity (one optional parameter, no required parameters) and that an output schema exists, the description adequately covers purpose, effect, and quota behavior. There is nothing missing that an agent would need to decide when and how to call it correctly.

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

Parameters3/5

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

The input schema already fully documents the 'source' parameter with 'Clear one source only; omit to clear everything' (100% schema coverage). The description adds no extra meaning about the parameter, so it meets the baseline but does not exceed it.

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 (drop cached distributor responses) and the goal (force fresh stock and pricing). This is a distinct resource and action, and none of the sibling tools (search_parts, source_status, part_details) perform cache clearing, so it's easily differentiated without opening the schema.

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 provides clear context that clearing the cache forces fresh data and makes subsequent searches consume real request budget, implying the tool should be used when fresh data is required. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of the full 'when/when-not' guidance.

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

part_detailsA

Look up one part by part number, with full specifications and pricing.

Distributor part numbers only resolve at the distributor that issued them, so a lookup by one distributor's number will normally return a result from that source alone.

ParametersJSON Schema

Name	Required	Description	Default
`sources`	No	Which distributors to query. Omit to query all configured sources.
`part_number`	Yes	Manufacturer part number, or a distributor part number such as 296-1234-ND for DigiKey, C22452 for LCSC or 511-LM317T for Mouser

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses a key behavioral trait: distributor part numbers only resolve at the issuing distributor, and results will normally come from that source alone. This is genuinely non-obvious and valuable. It does not mention auth, rate limits, or error handling, but for a lookup tool with an output schema, this covers the main gotcha.

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?

Two sentences, each earning its place. The first states the core purpose; the second delivers a critical behavioral caveat. No filler, no repetition, and the purpose is front-loaded. This is an efficient, well-structured description.

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

Completeness4/5

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

Given the tool's low complexity (2 parameters, 1 optional), the existence of an output schema, and the key distributor caveat being addressed, the description is functionally complete. It lacks only more explicit usage routing, which is covered under usage guidelines, but overall nothing essential is missing for safe invocation.

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

Parameters3/5

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

Schema coverage is 100%, and the schema already includes detailed descriptions for both parameters, including concrete examples for part_number (e.g., '296-1234-ND' for DigiKey) and the meaning of sources. The description adds no additional parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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 ('look up one part by part number'), the resource ('part'), and the scope ('full specifications and pricing'). It distinguishes from sibling tools: search_parts is for searching, source_status is for status, and clear_cache is for cache management. No ambiguity.

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 hints at when to use this tool (when you have a specific part number) versus searching, but it does not explicitly name alternatives or exclusion conditions. The distributor-resolution note gives behavioral context but not direct routing. Sibling differentiation is implied rather than stated.

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

search_partsA

Search DigiKey, LCSC and Mouser for electronic components.

Searches every configured distributor by default and merges offers for the same part number so prices can be compared. Pass sources to query one distributor on its own. If a distributor fails or is out of quota, results from the others are still returned and the failure is listed under errors.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum parts per source
`merge`	No	Group offers for the same part number into one entry with a price comparison. Set false to keep each distributor's results separate.
`keyword`	Yes	Part number, description or search phrase
`sources`	No	Which distributors to query: ['digikey'], ['lcsc'], ['mouser'], or any combination. Omit to search every configured source.
`quantity`	No	Quantity used for the price comparison
`manufacturer`	No	Restrict results to one manufacturer, by name
`in_stock_only`	No	Exclude parts with no stock
`include_specs`	No	Include parametric specifications

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior4/5

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

No annotations are provided, so the full burden falls on the description — and it delivers. It discloses aggregation (merges offers by part number), default scope (every configured distributor), and importantly the partial-failure semantics (a failing or quota-exhausted distributor still yields results from others, with the failure surfaced under errors). These are non-obvious behaviors not visible in the schema. No contradictions exist since no annotations were declared.

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?

Three tight, front-loaded sentences: purpose first, then merge behavior, then source-scoping and failure tolerance. Each sentence adds a distinct piece of information with no padding or repetition. Minor nit — 'electronic components' is slightly generic — but overall the structure is efficient and well-ordered.

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

Completeness4/5

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

For an 8-parameter multi-distributor tool with a 100%-coverage schema and an output schema present, the definition is largely complete: it covers default behaviors, the sources override, quantity/limit context, and edge-case handling. The one genuine gap is sibling routing — when the keyword is an exact part number, an agent may need guidance that part_details is the better fit. Minor given the overall richness.

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

Parameters3/5

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

Schema coverage is 100% — every one of the 8 parameters already carries a descriptive schema entry (limit, merge, keyword, sources, quantity, manufacturer, in_stock_only, include_specs). Baseline is therefore 3. The description adds marginal value by explaining the sources override and the merge default, but it does not compensate beyond what the schema already states.

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 opens with a specific verb and resource set: 'Search DigiKey, LCSC and Mouser for electronic components.' This is precise and clearly distinguishes the tool from its siblings — source_status checks health, part_details fetches a single part, clear_cache manages cache. An agent can tell this is the multi-distributor search tool without opening the schema.

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 thoroughly explains the tool's own operating behavior: default all-sources search, merging of same-part offers, the `sources` override, and failure tolerance. However, it never names an alternative or states when NOT to use it. Critically, since the `keyword` field accepts a part number, an agent could be torn between search_parts and part_details, and nothing here routes that choice. Context is strong, but explicit exclusions/alternatives are absent.

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

source_statusA

Report which distributors are configured and how much request budget is left.

Use this when a search reports a rate limit error, to see the configured limits and how many requests remain for the day.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden of disclosing behavior. It states the tool reports configuration and budget, which implies a read-only operation, but it does not explicitly clarify that it has no side effects or mention any caveats (e.g., caching, staleness). This is adequate but not exhaustive.

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 two concise sentences with the primary purpose front-loaded and the usage guidance immediately following. Every sentence earns its place, with no redundancy or filler.

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

Completeness5/5

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

Given the tool's simplicity (no parameters) and the existence of an output schema (so return values need not be described), the description fully covers what the tool does and when to use it. Nothing an agent needs to know to call it correctly is missing.

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

Parameters4/5

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

The input schema has zero parameters and 100% coverage (empty object), so the description has nothing to add for parameters. Per calibration, a tool with 0 parameters gets a baseline of 4, and the description does not detract from that.

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 states a specific verb ('Report') followed by the precise resource ('which distributors are configured and how much request budget is left'). It uniquely distinguishes this from sibling tools like search_parts or clear_cache, which clearly have different functions.

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 gives an explicit trigger condition ('Use this when a search reports a rate limit error'), making the intended context clear. However, it does not name alternatives or explicitly state when not to use it, so it misses the full when/when-not/alternatives structure that would merit a 5.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.1.0Aug 27, 2026
- First observedclear_cache
- First observedpart_details
- First observedsearch_parts
- First observedsource_status

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

Each tool serves a distinct purpose: searching across distributors, reporting status/quotas, fetching detailed part info, and clearing cache. There is no overlap or ambiguity between actions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (search_parts, source_status, part_details, clear_cache), making the API predictable and easy to navigate.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose of component search and comparison. Each tool earns its place, covering search, details, status, and cache management without bloat.

Completeness4/5

The core workflow is covered: search, view details, check quota, and manage cache. Minor gaps exist (e.g., no bulk operation or category browsing), but the essential lifecycle for a search-focused server is present.

Maintenance

ActivityMaintained

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

catalog A
ai.partsgraph
Search real parts with datasheet-provenance specs, check compatibility and compose priced BOMs.
Search E-commerce & Retail
111
Source PartsOAuth
io.github.SourceParts
Electronic component sourcing, BOM management, and PCB design workflows.
Developer Tools App Automation Product Management
21
sheetsdata-mcp A
io.github.octoco-ltd
Electronic component datasheets for AI agents — specs, pinouts, package data on demand.
Embedded system Developer Tools Research & Data
12210
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

Related MCP Servers

Nexar MCP Server
Search E-commerce & Retail Research & Data
phuhduong
A
license
Not graded
quality
Not graded
maintenance
Enables searching for electronic components through the Nexar Supply API, providing detailed part information including manufacturer, pricing, specifications, and datasheets.
Updated 10 months ago (2025-11-09 11:55 UTC)
-
Nexar MCP Server
E-commerce & Retail Search Developer Tools
Farad-Labs
F
license
Not graded
quality
C
maintenance
Enables searching for electronic components, comparing prices across distributors, checking availability, and retrieving datasheets through the Nexar/Octopart API with specialized tools for resistors, capacitors, inductors, semiconductors, crystals, and connectors.
Updated 9 months ago (2025-12-13 19:33 UTC)
8
-
DigiKey MCP Server
Search E-commerce & Retail Developer Tools
simon-77
A
license
Not graded
quality
D
maintenance
Provides access to the DigiKey Product Search API v4, allowing users to search for electronic components and retrieve detailed product specifications. It supports keyword searches, pricing inquiries, manufacturer lookups, and access to technical datasheets.
Updated 4 months ago (2026-05-14 11:26 UTC)
2
MIT
PCB Parts MCP Server
Developer Tools Search
Averyy
A
license
A
quality
A
maintenance
Enables searching and filtering over 1.5 million electronic components across JLCPCB, Mouser, and DigiKey using parametric queries and smart parsing. It supports finding alternative parts, accessing pinout data, and downloading KiCad footprints directly through AI coding assistants.
Updated 16 hours ago (2026-09-05 15:33 UTC)
11
106
MIT

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/tmpk13/eparts-search-mcp'

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