de en es ja ko ru zh

digi-mouse-search

Name: digi-mouse-search
Author: tmpk13

by tmpk13

Overview Schema Source Related Servers Discussions Admin

Python

Remote

eparts-search-mcp

Un servidor MCP que busca componentes electrónicos en DigiKey, LCSC y Mouser. Cada distribuidor se puede consultar por separado o todos juntos, fusionando las ofertas del mismo número de pieza en una sola entrada para poder comparar precios.

Herramientas

Herramienta	Propósito
`search_parts`	Búsqueda por palabra clave en uno o varios distribuidores
`part_details`	Consulta de una sola pieza por número de pieza del fabricante o del distribuidor
`source_status`	Qué fuentes están configuradas y cuánto presupuesto de solicitudes queda
`clear_cache`	Elimina las respuestas en caché para forzar stock y precios actualizados

search_parts acepta una lista sources. Si se omite, busca en todos los distribuidores configurados; si se pasa ["mouser"], busca solo en ese. Los resultados se fusionan por número de pieza por defecto, con una comparación cheapest_at_quantity; pasa merge=false para mantener los resultados de cada distribuidor en una lista separada.

La comparación solo considera ofertas que tienen un precio en la cantidad solicitada. LCSC vende muchas piezas en múltiplos de diez, por lo que a una cantidad de uno, una oferta así no tiene un tramo aplicable y se excluye de la comparación en lugar de contarse como gratuita.

Si un distribuidor falla, no está configurado o ha agotado su cuota, los demás siguen devolviendo resultados y el fallo se informa en errors.

Related MCP server: Nexar MCP Server

Instalación

Para usar el servidor desde cualquier lugar del sistema, instálalo como una herramienta independiente. El ejecutable se coloca en ~/.local/bin ($XDG_BIN_HOME si está definido), con sus dependencias en su propio entorno bajo ~/.local/share/uv/tools:

uv tool install .

mise run install-tool hace lo mismo, y mise run uninstall-tool lo elimina. Después de instalar, eparts-search-mcp ejecuta el servidor en stdio desde cualquier directorio, leyendo las credenciales del archivo de configuración XDG descrito a continuación. No se toca nada fuera de ~/.local y ~/.config, por lo que no se necesita un paso de instalación privilegiado.

Asegúrate de que ~/.local/bin esté en PATH:

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

Configuración de desarrollo

Para trabajar en el servidor en lugar de usarlo:

mise install
mise run install
mise run test

Las credenciales pueden provenir de un archivo de configuración o del entorno. El archivo las mantiene fuera del entorno y de los listados de procesos; se lee por defecto desde ~/.config/eparts-search-mcp/config.toml (o $XDG_CONFIG_HOME si está definido), por lo que no se necesita EPARTS_CONFIG:

# ~/.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 = "..."

Como el archivo contiene secretos, mantenlo legible solo para ti. El servidor advierte al inicio si es accesible para el grupo u otros:

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

Los mismos valores también pueden suministrarse a través del entorno, que anula el archivo:

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

Solo se necesitan las credenciales de los distribuidores que realmente quieras. Una fuente sin credenciales se informa como no configurada en lugar de hacer fallar la búsqueda.

Obtención de credenciales

DigiKey. Una aplicación de desarrollador personal solo obtiene acceso de sandbox, y el sandbox devuelve datos sintéticos. Para stock y precios reales necesitas una aplicación de Producción, que vive bajo una Organización:

Inicia sesión en developer.digikey.com con tu cuenta de DigiKey.
Abre Organizations en la barra de navegación y crea una si aún no eres miembro.
En Operations, elige Production Apps y luego Create Production App.
Habilita Product Information para la aplicación.
Abre la aplicación para copiar su Client ID y Client Secret.

El campo de devolución de llamada OAuth solo se usa en OAuth de tres patas. Este servidor usa el flujo de credenciales de cliente de dos patas, por lo que la devolución de llamada nunca se redirige; https://localhost satisface el formulario.

Las credenciales de sandbox y producción no son intercambiables. Las credenciales de sandbox solo funcionan contra sandbox-api.digikey.com, que es lo que selecciona DIGIKEY_SANDBOX=true.

LCSC. La API abierta es una integración de socio en lugar de un registro de autoservicio, por lo que las credenciales provienen de un administrador de cuentas de LCSC después de que la dirección IP de llamada haya sido incluida en la lista blanca. La incorporación comienza en un entorno de prueba en un host separado (fatapi.lcsc.com) que responde con datos de catálogo simulados; LCSC_SANDBOX=true lo selecciona. Las credenciales de producción llegan una vez que la integración está aprobada y se usan contra api.lcsc.com.

Una llamada se autentica mediante una firma SHA-256 sobre los parámetros de la solicitud, la clave, un nonce por solicitud y una marca de tiempo. El secreto es una entrada de ese hash y nunca se transmite, por lo que nunca aparece en una URL o en un registro; la marca de tiempo se verifica, lo que significa que un reloj del sistema muy desajustado se lee como una solicitud caducada en lugar de una clave rechazada.

Mouser. Solicita una clave de API de búsqueda en mouser.com/api-hub. Es una clave única, enviada como parámetro de consulta, y llega por correo electrónico.

Configuración del cliente MCP

Una vez instalado como se indicó arriba, el comando está en PATH y no necesita ruta ni entorno, ya que las credenciales provienen del archivo de configuración:

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

Algunos clientes lanzan servidores con un entorno mínimo que no incluye ~/.local/bin; usa la ruta absoluta allí en su lugar:

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

Para ejecutar desde un checkout de código fuente sin instalar, o para pasar credenciales a través del cliente en lugar del archivo de configuración:

{
  "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": "..."
      }
    }
  }
}

Límites de velocidad

Cada distribuidor otorga aproximadamente mil llamadas por día, por lo que cada solicitud está presupuestada. Las ventanas por segundo y por minuto se aplican esperando; la ventana diaria es una parada dura que informa un error en su lugar, ya que un llamador no puede esperar útilmente una cuota que se restablece a medianoche. El contador diario se persiste, por lo que reiniciar el servidor no lo restablece.

Valores predeterminados:

Ventana	DigiKey	LCSC	Mouser
por segundo	2	1	1
por minuto	60	45	25
por día	1000	1000	1000
ráfaga	5	5	3
espera máxima	10 s	10 s	10 s

LCSC documenta 60 búsquedas por palabra clave por minuto y mil por día, y solo cuenta las llamadas que tienen éxito. Su valor predeterminado por minuto se establece por debajo del techo documentado, ya que ser limitado por el distribuidor cuesta más que esperar localmente. Cuando el propio contador de LCSC rechaza una llamada de todos modos, el error lo dice, para distinguirlo del presupuesto local.

Cada valor es configurable por proveedor, ya sea mediante variable de entorno o mediante un archivo TOML. Usa none, off, unlimited o 0 para deshabilitar una ventana:

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

Estos también viven en el archivo de configuración (~/.config/eparts-search-mcp/config.toml por defecto, o donde apunte EPARTS_CONFIG), consulta config.example.toml. Las variables de entorno anulan el archivo, por lo que un comando de lanzamiento del cliente puede ajustar un límite sin editar la configuración en disco.

Las respuestas en caché se sirven sin gastar presupuesto. source_status informa lo que queda para el día.

Otros ajustes

Variable	Predeterminado	Significado
`EPARTS_CONFIG`	`~/.config/eparts-search-mcp/config.toml`	Ruta a un archivo de configuración TOML; se lee la ubicación predeterminada si no está definida
`EPARTS_CACHE_PATH`	`$XDG_STATE_HOME/eparts-search-mcp/cache.sqlite3`	Base de datos de caché y uso
`EPARTS_CACHE_TTL`	3600	Vida útil de la respuesta en caché en segundos
`EPARTS_REQUEST_TIMEOUT`	30	Tiempo de espera HTTP en segundos
`DIGIKEY_SANDBOX`	false	Usa el host de sandbox de DigiKey, que devuelve datos sintéticos
`DIGIKEY_LOCALE_SITE`	US	Sitio de DigiKey a buscar
`DIGIKEY_LOCALE_CURRENCY`	USD	Moneda para los precios de DigiKey
`DIGIKEY_LOCALE_LANGUAGE`	en	Idioma para los resultados de DigiKey
`LCSC_SANDBOX`	false	Usa el host de prueba de LCSC, que devuelve datos simulados
`LCSC_CURRENCY`	USD	Moneda para los precios de LCSC: USD, EUR, HKD o CNY
`LCSC_LANGUAGE`	EN	Idioma para los resultados de LCSC: EN o CN

Archivos en disco

Todo lo que el servidor guarda vive bajo los directorios base XDG, por lo que una instalación no posee nada fuera del directorio de inicio:

Qué	Dónde
Ejecutable	`$XDG_BIN_HOME`, es decir, `~/.local/bin/eparts-search-mcp`
Entorno de la herramienta	`~/.local/share/uv/tools/eparts-search-mcp`
Credenciales y ajustes	`$XDG_CONFIG_HOME/eparts-search-mcp/config.toml`
Caché y contadores de uso diario	`$XDG_STATE_HOME/eparts-search-mcp/cache.sqlite3`

XDG_CONFIG_HOME y XDG_STATE_HOME se establecen por defecto en ~/.config y ~/.local/state cuando no están definidos. EPARTS_CONFIG y EPARTS_CACHE_PATH anulan los dos últimos. Desinstalar con uv tool uninstall eparts-search-mcp deja la configuración y la caché en su lugar; elimina esos directorios para quitarlos también.

Arquitectura

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

Flujo de solicitud para una llamada de proveedor:

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

Notas sobre las tres APIs

DigiKey usa credenciales de cliente OAuth2. El token dura diez minutos y se almacena en caché en memoria; las solicitudes necesitan el encabezado de ID de cliente junto con el token de portador. Los filtros se expresan como IDs opacos, por lo que un nombre de fabricante se resuelve primero a través del endpoint de fabricantes.

LCSC firma cada solicitud en lugar de llevar un token: la clave, un nonce, una marca de tiempo y los parámetros de consulta ordenados se mezclan con el secreto, y el resumen viaja en un encabezado. Al igual que Mouser, responde con HTTP 200 incluso cuando la solicitud falló, poniendo el resultado real en el campo code del cuerpo, que el adaptador trata como autoritativo. No hay un endpoint por pieza, por lo que una consulta de detalles es una búsqueda por palabra clave de la que se extrae la coincidencia exacta; una búsqueda por palabra clave que devuelve solo coincidencias cercanas no produce ningún resultado en lugar de uno plausible incorrecto. Tampoco hay filtro de fabricante, por lo que un fabricante se incorpora a la palabra clave y los resultados se filtran en el camino de regreso.

Mouser usa una clave de API pasada como parámetro de consulta y responde con HTTP 200 incluso cuando la solicitud falló, poniendo el fallo en un array Errors. El adaptador trata ese array como autoritativo. Los precios llegan como cadenas de visualización localizadas en lugar de números.

Las especificaciones paramétricas no tienen un vocabulario compartido entre los tres distribuidores, por lo que se pasan como un mapa de nombre/valor en lugar de normalizarse en un esquema común. El recargo por bobina de LCSC se informa de la misma manera, ya que es una tarifa por pedido que la escalera de precios por unidad no puede expresar.

Claude Code se utilizó en la creación de esta herramienta.

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.

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

Output 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.

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

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.

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

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.

Name	Required	Description	Default
No parameters

Output 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.

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

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-08-27 01:50 across 4 tools

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

ActivitySlowing

ResponsivenessNo issues

Resources

Related MCP Connectors

Next Everything A
io.nexteverything
Find electronic parts with live Mouser, DigiKey and JLCPCB stock and prices, check BOMs, order.
E-commerce & Retail App Automation Data Platforms
81
https://mcp.nexteverything.io/mcp
catalog A
ai.partsgraph
Search real parts with datasheet-provenance specs, check compatibility and compose priced BOMs.
Search E-commerce & Retail
111
https://partsgraph.ai/api/mcp
Source PartsOAuth
io.github.SourceParts
Electronic component sourcing, BOM management, and PCB design workflows.
Developer Tools App Automation Product Management
22
https://mcp.source.parts/
SheetsData A
io.github.octoco-ltd
Electronic component datasheets for AI agents: pinouts, specs, package info and design checks.
Embedded system Developer Tools Research & Data
14213
https://mcp.sheetsdata.com/mcp

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 a year 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 a year ago (2025-12-13 19:33 UTC)
11
-
DigiKey MCP Server
Search E-commerce & Retail Developer Tools
simon-77
A
license
Not graded
quality
F
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 5 months ago (2026-05-14 11:26 UTC)
3
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 2 days ago (2026-10-26 18:58 UTC)
11
134
MIT