eparts-search-mcp

Ein MCP-Server, der elektronische Bauteile bei DigiKey, LCSC und Mouser durchsucht. Jeder Distributor kann einzeln oder alle zusammen abgefragt werden, wobei Angebote für dieselbe Teilenummer zu einem einzigen Eintrag zusammengeführt werden, sodass Preise verglichen werden können.

Werkzeuge

search_parts akzeptiert eine sources-Liste. Wenn sie weggelassen wird, werden alle konfigurierten Distributoren durchsucht; mit ["mouser"] wird nur dieser eine durchsucht. Die Ergebnisse werden standardmäßig nach Teilenummer zusammengeführt, mit einem cheapest_at_quantity-Vergleich; mit merge=false bleiben die Ergebnisse jedes Distributors in einer separaten Liste.

Der Vergleich berücksichtigt nur Angebote, die einen Preis für die angefragte Menge haben. LCSC verkauft viele Bauteile in Zehnereinheiten, sodass ein solches Angebot bei einer Menge von eins keine anwendbare Preisstufe hat und aus dem Vergleich ausgelassen wird, anstatt als kostenlos gezählt zu werden.

Wenn ein Distributor fehlschlägt, nicht konfiguriert ist oder sein Kontingent erschöpft hat, liefern die anderen weiterhin Ergebnisse, und der Fehler wird unter errors gemeldet.

Related MCP server: Nexar MCP Server

Installation

Um den Server von überall im System aus zu verwenden, installieren Sie ihn als eigenständiges Werkzeug. Die ausführbare Datei landet in ~/.local/bin ($XDG_BIN_HOME, falls gesetzt), mit ihren Abhängigkeiten in einer eigenen Umgebung unter ~/.local/share/uv/tools:

uv tool install .

mise run install-tool macht dasselbe, und mise run uninstall-tool entfernt es. Nach der Installation führt eparts-search-mcp den Server über stdio aus jedem Verzeichnis aus und liest die Anmeldedaten aus der unten beschriebenen XDG-Konfigurationsdatei. Außerhalb von ~/.local und ~/.config wird nichts verändert, daher ist kein privilegierter Installationsschritt erforderlich.

Stellen Sie sicher, dass ~/.local/bin im PATH liegt:

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

Entwicklungseinrichtung

Für die Arbeit am Server statt seiner Verwendung:

mise install
mise run install
mise run test

Anmeldedaten können aus einer Konfigurationsdatei oder der Umgebung stammen. Die Datei hält sie aus der Umgebung und Prozesslisten heraus; sie wird standardmäßig aus ~/.config/eparts-search-mcp/config.toml (oder $XDG_CONFIG_HOME, falls gesetzt) gelesen, sodass kein EPARTS_CONFIG erforderlich ist:

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

Da die Datei Geheimnisse enthält, sollte sie nur für Sie lesbar sein. Der Server warnt beim Start, wenn sie für Gruppe oder andere zugänglich ist:

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

Dieselben Werte können stattdessen über die Umgebung bereitgestellt werden, die die Datei überschreibt:

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

Es werden nur die Anmeldedaten der Distributoren benötigt, die Sie tatsächlich verwenden möchten. Eine Quelle ohne Anmeldedaten wird als nicht konfiguriert gemeldet, anstatt die Suche fehlschlagen zu lassen.

Anmeldedaten erhalten

DigiKey. Eine persönliche Entwickler-App erhält nur Sandbox-Zugriff, und die Sandbox liefert synthetische Daten. Für echte Bestände und Preise benötigen Sie eine Produktions-App, die unter einer Organisation läuft:

1. Melden Sie sich bei developer.digikey.com mit Ihrem DigiKey-Konto an.

2. Öffnen Sie Organizations in der Navigationsleiste und erstellen Sie eine, falls Sie nicht bereits Mitglied sind.

3. Wählen Sie unter Operations die Option Production Apps und dann Create Production App.

4. Aktivieren Sie Product Information für die App.

5. Öffnen Sie die App, um ihre Client ID und ihr Client Secret zu kopieren.

Das OAuth-Callback-Feld wird nur für dreibeiniges OAuth verwendet. Dieser Server verwendet den zweibeinigen Client-Credentials-Ablauf, sodass das Callback nie umgeleitet wird; https://localhost erfüllt das Formular.

Sandbox- und Produktionsanmeldedaten sind nicht austauschbar. Sandbox-Anmeldedaten funktionieren nur gegen sandbox-api.digikey.com, was durch DIGIKEY_SANDBOX=true ausgewählt wird.

LCSC. Die Open API ist eine Partnerintegration und keine Selbstbedienungs-Anmeldung, daher stammen die Anmeldedaten von einem LCSC-Kontomanager, nachdem die aufrufende IP-Adresse auf die Whitelist gesetzt wurde. Das Onboarding beginnt in einer Testumgebung auf einem separaten Host (fatapi.lcsc.com), der mit simulierten Katalogdaten antwortet; LCSC_SANDBOX=true wählt diese aus. Produktionsanmeldedaten treffen ein, sobald die Integration abgenommen ist, und werden gegen api.lcsc.com verwendet.

Ein Aufruf wird durch eine SHA-256-Signatur über die Anforderungsparameter, den Schlüssel, eine Nonce pro Anforderung und einen Zeitstempel authentifiziert. Das Geheimnis ist eine Eingabe in diesen Hash und wird nie übertragen, sodass es nie in einer URL oder einem Protokoll erscheint; der Zeitstempel wird geprüft, was bedeutet, dass eine stark falsche Systemuhr als abgelaufene Anforderung gelesen wird und nicht als abgelehnter Schlüssel.

Mouser. Fordern Sie einen Search-API-Schlüssel unter mouser.com/api-hub an. Es ist ein einzelner Schlüssel, der als Abfrageparameter gesendet wird und per E-Mail eintrifft.

MCP-Client-Konfiguration

Nach der Installation wie oben ist der Befehl im PATH und benötigt weder Pfad noch Umgebung, da die Anmeldedaten aus der Konfigurationsdatei stammen:

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

Einige Clients starten Server mit einer leeren Umgebung, die ~/.local/bin nicht enthält; geben Sie stattdessen den absoluten Pfad an:

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

Um aus einem Quellcode-Checkout ohne Installation zu laufen oder Anmeldedaten über den Client statt über die Konfigurationsdatei zu übergeben:

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

Ratenbegrenzungen

Jeder Distributor gewährt ungefähr tausend Aufrufe pro Tag, daher wird jede Anforderung budgetiert. Fenster pro Sekunde und pro Minute werden durch Warten durchgesetzt; das Tagesfenster ist ein harter Stopp, der stattdessen einen Fehler meldet, da ein Aufrufer nicht sinnvoll auf ein Kontingent warten kann, das um Mitternacht zurückgesetzt wird. Der Tageszähler wird gespeichert, sodass ein Neustart des Servers ihn nicht zurücksetzt.

Standardwerte:

LCSC dokumentiert 60 Stichwortsuchanfragen pro Minute und tausend pro Tag und zählt nur erfolgreiche Aufrufe. Sein Standardwert pro Minute ist unter der dokumentierten Obergrenze angesetzt, da eine Drosselung durch den Distributor mehr kostet als lokales Warten. Wenn LCSCs eigener Zähler einen Aufruf dennoch ablehnt, sagt der Fehler dies aus, um ihn vom lokalen Budget zu unterscheiden.

Jeder Wert ist pro Anbieter konfigurierbar, entweder über eine Umgebungsvariable oder eine TOML-Datei. Verwenden Sie none, off, unlimited oder 0, um ein Fenster zu deaktivieren:

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

Diese stehen auch in der Konfigurationsdatei (standardmäßig ~/.config/eparts-search-mcp/config.toml oder wo auch immer EPARTS_CONFIG zeigt), siehe config.example.toml. Umgebungsvariablen überschreiben die Datei, sodass ein Client-Startbefehl ein Limit anpassen kann, ohne die Konfiguration auf der Festplatte zu bearbeiten.

Zwischengespeicherte Antworten werden ohne Budgetverbrauch ausgeliefert. source_status meldet, was für den Tag noch übrig ist.

Weitere Einstellungen

Dateien auf der Festplatte

Alles, was der Server speichert, befindet sich unter den XDG-Basisverzeichnissen, sodass eine Installation nichts außerhalb des Home-Verzeichnisses besitzt:

XDG_CONFIG_HOME und XDG_STATE_HOME standardmäßig auf ~/.config bzw. ~/.local/state, wenn nicht gesetzt. EPARTS_CONFIG und EPARTS_CACHE_PATH überschreiben die letzten beiden. Die Deinstallation mit uv tool uninstall eparts-search-mcp lässt Konfiguration und Cache an Ort und Stelle; löschen Sie diese Verzeichnisse, um auch sie zu entfernen.

Architektur

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

Anforderungsablauf für einen Anbieteraufruf:

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

Anmerkungen zu den drei APIs

DigiKey verwendet OAuth2-Client-Anmeldedaten. Das Token hält zehn Minuten und wird im Speicher zwischengespeichert; Anforderungen benötigen den Client-ID-Header zusammen mit dem Bearer-Token. Filter werden als undurchsichtige IDs ausgedrückt, daher wird ein Herstellername zunächst über den Hersteller-Endpunkt aufgelöst.

LCSC signiert jede Anforderung, anstatt ein Token mitzuführen: Der Schlüssel, eine Nonce, ein Zeitstempel und die sortierten Abfrageparameter werden mit dem Geheimnis gehasht, und der Digest reist in einem Header. Wie Mouser antwortet es auch bei fehlgeschlagenen Anforderungen mit HTTP 200 und legt das tatsächliche Ergebnis in das code-Feld des Bodys, das der Adapter als maßgeblich behandelt. Es gibt keinen Endpunkt pro Bauteil, daher ist eine Detailabfrage eine Stichwortsuche, aus der die exakte Übereinstimmung herausgepickt wird; eine Stichwortsuche, die nur nahe Übereinstimmungen liefert, ergibt kein Ergebnis statt eines plausiblen falschen. Es gibt auch keinen Herstellerfilter, daher wird ein Hersteller in das Stichwort aufgenommen und die Ergebnisse werden auf dem Rückweg gefiltert.

Mouser verwendet einen API-Schlüssel, der als Abfrageparameter übergeben wird, und antwortet auch bei fehlgeschlagenen Anforderungen mit HTTP 200, wobei der Fehler in einem Errors-Array abgelegt wird. Der Adapter behandelt dieses Array als maßgeblich. Preise kommen als lokalisierte Anzeigezeichenfolgen statt als Zahlen.

Parametrische Spezifikationen haben kein gemeinsames Vokabular zwischen den drei Distributoren, daher werden sie als Name/Wert-Zuordnung durchgereicht, anstatt in ein gemeinsames Schema normalisiert zu werden. LCSCs Rollenzuschlag wird auf dieselbe Weise gemeldet, da es sich um eine Gebühr pro Bestellung handelt, die die Preisstaffel pro Einheit nicht ausdrücken kann.

Claude Code wurde bei der Erstellung dieses Werkzeugs verwendet.