MCP für Hersteller: Ein Praxisleitfaden

Was ist MCP, ganz einfach erklärt?

Das Model Context Protocol ist ein standardisierter Weg, auf dem ein KI-Assistent das System eines anderen aufruft und eine typisierte, strukturierte Antwort zurückerhält.

Anthropic hat es am 25. November 2024 als Open Source veröffentlicht und dabei als „einen neuen Standard für die Anbindung von KI-Assistenten an die Systeme, in denen die Daten liegen“ beschrieben. Am 9. Dezember 2025 hat Anthropic MCP an die Agentic AI Foundation übergeben, einen zweckgebundenen Fonds unter dem Dach der Linux Foundation, der gemeinsam mit Block und OpenAI gegründet wurde und von AWS, Bloomberg, Cloudflare, Google und Microsoft auf Platin-Ebene getragen wird. Zu diesem Zeitpunkt hatte MCP 97 Millionen monatliche SDK-Downloads und mehr als 10.000 veröffentlichte Server überschritten, bei erstklassiger Client-Unterstützung in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot und VS Code.

Für Entscheider ohne Entwicklerhintergrund kommt es auf diesen Unterschied an. Wenn ein Assistent Ihre Website liest, interpretiert er ein Dokument: Er kann eine Tabelle falsch lesen, eine Fußnote übersehen oder zwei Varianten vermischen. Wenn ein Assistent Ihren MCP-Server aufruft, fragt er ein System ab: Er fordert das Teil an, erhält die Felder und gibt sie wieder. Der erste Modus liefert plausible Antworten. Der zweite liefert richtige – vorausgesetzt, die Daten dahinter stimmen, und genau dort steckt der größte Teil der eigentlichen Arbeit.

Wer hat in dieser Branche bereits einen ausgeliefert?

Das ist längst keine Spekulation mehr, und die Beispiele sind aufschlussreich unterschiedlich:

• Microchip Technology hat am 6. November 2025 einen kostenlosen, öffentlichen MCP-Server gestartet, der verifizierte Produktspezifikationen, Datenblätter, Lagerbestände, Preise und Lieferzeiten über MCP Streamable HTTP bereitstellt – mit JSON-codierten Antworten für Copiloten, Chatbots und Unternehmensagenten.
• Siemens betreibt unter mcp.siemens.com einen öffentlichen Server, dessen dokumentierte Plug-ins – Assets, Entwicklerportal, Suche und Web-Inhalte – ohne Authentifizierung verfügbar sind.
• Zoovu hat am 11. Dezember 2025 einen MCP-Server gestartet, der Agenten geregelten Zugriff auf Produktdaten gibt und sich über die Genauigkeit bei Kompatibilitäts- und Anwendungsfragen positioniert.
• ECIA hat am 11. Juni 2026 den TrustedParts.com Inventory AI Agent Service gestartet und damit autorisierte Lagerbestände für elektronische Bauteile in Microsoft Copilot, ChatGPT und Claude verfügbar gemacht.
• Shopify stellt in Shops unter https://{shop}.myshopify.com/api/mcp einen Storefront-MCP-Server bereit, mit Tools wie search_catalog, lookup_catalog und get_product und ohne Authentifizierungspflicht für die Storefront-Ebene.

Zwei Muster verdienen Beachtung. Jeder dieser Server setzt auf einem bereits vorhandenen, führenden Datenbestand auf. Und jeder von ihnen zieht eine klare Linie zwischen öffentlichen Katalogdaten und allem, was kommerziell sensibel ist.

Tools oder Resources – was sollte ein Teile-Server nutzen?

Die Spezifikation ist beim Unterschied eindeutig, und wer ihn verfehlt, baut einen Server, den Modelle schlecht nutzen.

Tools sind modellgesteuert. Die Spezifikation hält fest, dass Tools „modellgesteuert konzipiert sind, was bedeutet, dass das Sprachmodell Tools auf Basis seines Kontextverständnisses und der Prompts des Nutzers automatisch entdecken und aufrufen kann“. Die Entdeckung erfolgt über tools/list, der Aufruf über tools/call. Jedes Tool trägt ein inputSchema (standardmäßig JSON Schema 2020-12), optional ein outputSchema und gibt structuredContent zurück, das diesem Schema entspricht.

Resources sind anwendungsgesteuert. Die Spezifikation hält fest, dass Resources „anwendungsgesteuert konzipiert sind, wobei die Host-Anwendungen entsprechend ihren Anforderungen bestimmen, wie sie Kontext einbinden“ – typischerweise über eine Auswahl, eine Liste oder die automatische Einbindung durch den Host. Jede Resource wird über eine URI identifiziert, und Templates erlauben parametrisierte URIs.

Ein Katalog ist ein Abfrageraum, keine feste Dokumentmenge. Niemand möchte durch eine Resource-Auswahl mit 40.000 Teilen scrollen. Der Großteil eines Teile-Servers sollte deshalb aus Tools bestehen, mit zwei Verfeinerungen: Verwenden Sie resource_link-Content-Blöcke, um auf Datenblätter und CAD-Dateien zu verweisen, statt große Payloads inline mitzuschicken, und reservieren Sie echte Resources für eine Handvoll stabiler Dokumente wie ein Klassifikationswörterbuch oder ein Änderungsprotokoll.

Zwei Details der aktuellen Spezifikation lohnen die Aufmerksamkeit. Tool-Listen dürfen nicht je Verbindung variieren, dürfen aber je nach der mit der Anfrage vorgelegten Autorisierung unterschiedlich ausfallen. Und Server sollten Tools in einer deterministischen Reihenfolge zurückgeben, denn eine stabile Reihenfolge erlaubt Clients das Zwischenspeichern der Liste und verbessert die Trefferquote des Prompt-Cache.

Was hat sich in der Spezifikation 2026-07-28 geändert?

Diese Revision hat den Transport umgestaltet, und jedes Design, das auf Material aus dem Jahr 2025 beruht, ist in ganz bestimmten Punkten falsch.

Die Form des Transports ist inzwischen wohltuend unspektakulär. Der Server stellt einen einzigen MCP-Endpunkt bereit, der POST entgegennimmt – zum Beispiel https://example.com/mcp. Jede JSON-RPC-Anfrage ist ein eigener POST. Clients müssen einen Accept-Header senden, der sowohl application/json als auch text/event-stream aufführt, dazu einen MCP-Protocol-Version-Header, der mit dem Wert im _meta des Bodys übereinstimmen muss – andernfalls muss der Server mit 400 und einem HeaderMismatch-Fehler ablehnen. Server müssen den Origin-Header prüfen und mit 403 antworten, wenn er vorhanden und ungültig ist.

Die praktische Konsequenz für Infrastrukturteams: Da es keine Sitzung auf Protokollebene gibt, lässt sich Ihr MCP-Server wie jeder andere zustandslose HTTP-Dienst hinter einem einfachen Round-Robin-Load-Balancer betreiben. Roots, Sampling und Logging gelten nun mit einer Mindestfrist von zwölf Monaten als veraltet, und auch der alte HTTP+SSE-Transport ist formal als veraltet eingestuft.

Wie sichern Sie Preis und Bestand mit OAuth ab?

Autorisierung ist in MCP optional, und das ist für einen Teile-Server genau richtig: Der öffentliche Katalog sollte überhaupt kein Token benötigen, und nur kommerziell sensible Tools sollten eine Authentifizierung einfordern.

Wenn Sie sie umsetzen, sind die Anforderungen konkret. Der MCP-Server fungiert als OAuth-2.1-Resource-Server gemäß dem IETF-Entwurf zu OAuth 2.1. Er muss Protected Resource Metadata (RFC 9728) implementieren, und Clients müssen diese Metadaten für die Discovery des Autorisierungsservers nutzen. Clients müssen Resource Indicators (RFC 8707) umsetzen und dabei sowohl in Autorisierungs- als auch in Token-Anfragen einen resource-Parameter senden, der die kanonische URI Ihres Servers benennt; Ihr Server muss prüfen, dass Tokens für ihn als vorgesehene Audience ausgestellt wurden. Autorisierungsserver sollten gemäß RFC 9207 den Parameter iss zurückgeben, und Clients müssen ihn validieren. Dynamic Client Registration gilt inzwischen zugunsten von Client ID Metadata Documents als veraltet, bleibt aus Gründen der Abwärtskompatibilität aber verfügbar.

Das Muster, das für Distributoren und Hersteller funktioniert:

1. 01Nicht authentifizierte Ebene – Spezifikationen, parametrische Suche, Alternativen, Konformitätsdokumente, CAD-Links und Listenpreise, sofern Sie diese veröffentlichen.
2. 02Authentifizierte Ebene – Vertragspreise, kundenspezifische Verfügbarkeit, Angebotserstellung. Fordern Sie mit einem 403 und error="insufficient_scope" auf und benennen Sie die erforderlichen Scopes, damit der Client in einem einzigen Roundtrip statt in mehreren nachautorisieren kann.
3. 03Setzen Sie niemals eine Kundenkennung in einem Tool-Argument als einzige Zugriffskontrolle ein. Ein Handle ist ein Name, keine Berechtigung; prüfen Sie die Autorisierung bei jedem Aufruf.

Was sollte ein Teile-MCP-Server bereitstellen?

Sechs bis acht Tools sind die richtige Größenordnung. Darüber hinaus verschlechtert sich die Tool-Auswahl des Modells.

Eine Tool-Definition sollte unspektakulär aussehen – und genau das ist der Punkt:

{
  "name": "search_parts",
  "title": "Parametric part search",
  "description": "Search the catalog by product class and typed parameter constraints. Returns matching parts with their key parametrics, units and last-verified date. Use get_part for the full record.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "product_class": { "type": "string", "description": "ETIM class code or class name" },
      "constraints": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "parameter": { "type": "string" },
            "operator": { "type": "string", "enum": ["eq", "gte", "lte", "between", "in"] },
            "value": {},
            "unit": { "type": "string" }
          },
          "required": ["parameter", "operator", "value"]
        }
      },
      "limit": { "type": "integer", "default": 20 }
    },
    "required": ["product_class"],
    "additionalProperties": false
  }
}

Beachten Sie, was die Beschreibung leistet: Sie sagt dem Modell, was das Tool zurückgibt, und wann es zu einem anderen Tool greifen sollte. Diese eine Gewohnheit bringt für die Antwortqualität mehr als jede noch so ausgefeilte Schemapflege.

Ein durchgespieltes Beispiel

Ein Entwicklungsingenieur bei einem Auftragsfertiger in Texas ersetzt ein abgekündigtes Bauteil auf einer Baugruppe, die auch an einen deutschen Schaltschrankbauer geliefert wird. Der Assistent hat den MCP-Server des Herstellers verbunden.

Ingenieur: Der 60-V-N-Kanal-MOSFET in unserer Buck-Stufe wird abgekündigt. Ich brauche einen Drop-in im gleichen Gehäuse, R_DS(on) nicht schlechter als 12 Milliohm bei 10 V Gate-Ansteuerung, und ich muss wissen, ob er tatsächlich verfügbar ist.

Der Assistent setzt vier Aufrufe ab.

→ tools/call  get_part
   { "part_number": "XYZ-60N12-D2PAK" }
← structuredContent
   { "package": "D2PAK", "vds_v": 60, "rds_on_mohm": 11.5,
     "vgs_meas_v": 10, "lifecycle": "EOL", "last_verified": "2026-08-04" }

→ tools/call  find_alternates
   { "part_number": "XYZ-60N12-D2PAK", "basis": "form_fit_function" }
← structuredContent
   [ { "part_number": "XYZ-60N10-D2PAK", "equivalence": "drop-in",
       "rds_on_mohm": 9.8, "differences": ["lower R_DS(on)", "higher Qg"] },
     { "part_number": "XYZ-60N14-D2PAK", "equivalence": "footprint",
       "rds_on_mohm": 13.5, "differences": ["exceeds R_DS(on) limit"] } ]

→ tools/call  get_availability
   { "part_numbers": ["XYZ-60N10-D2PAK"] }
← 403 Forbidden
   WWW-Authenticate: Bearer error="insufficient_scope",
     scope="stock:read", resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

   [client performs step-up authorisation, then retries]

← structuredContent
   { "part_number": "XYZ-60N10-D2PAK",
     "stock": [ { "location": "US-TX", "qty": 14200 },
                { "location": "DE-BW", "qty": 3800 } ],
     "lead_time_weeks": 8, "as_of": "2026-08-09T06:12:00Z" }

→ tools/call  get_compliance_documents
   { "part_number": "XYZ-60N10-D2PAK", "types": ["rohs", "reach"] }
← content: [ { "type": "resource_link", "uri": "https://…/rohs-2026-03.pdf",
               "name": "RoHS declaration (issued 2026-03-11)" } ]

Der Assistent antwortet daraufhin: Ein Kandidat ist ein Drop-in mit besserem Durchlasswiderstand und höherer Gate-Ladung, was gegen den Gate-Treiber geprüft werden sollte; der zweite passt zum Footprint, verfehlt aber die R_DS(on)-Grenze; der Bestand liegt heute Morgen bei 14.200 Stück in Texas und 3.800 in Baden-Württemberg, bei acht Wochen Lieferzeit; die RoHS- und REACH-Erklärungen liegen mit ihrem Ausstellungsdatum bei.

Technisch ist daran nichts beeindruckend. Beeindruckend ist es als Geschäftsvorgang. Drei Beschaffungsentscheidungen wurden getroffen, ohne dass ein Mensch einen Browser geöffnet hat, und jede Zahl ist auf einen mit Zeitstempel versehenen Datensatz zurückführbar.

Wer kann Ihren Server heute tatsächlich erreichen?

Seien Sie hier gegenüber Ihrer Geschäftsführung ehrlich, denn die Antwort fällt enger aus, als die meisten Anbieterunterlagen nahelegen.

MCP erreicht also Ingenieure mit einem selbst konfigurierten Assistenten und Enterprise-Einkäufer, deren IT-Abteilung Ihren Server registriert. Nach Maßstäben des Webs ist das eine kleine Zielgruppe – nach Maßstäben der Vertriebspipeline eine sehr große.

Wie entdecken Agenten Ihren Server?

Eine Discovery auf DNS-Ebene gibt es nicht. Es existieren drei Mechanismen:

1. 01Die offizielle MCP-Registry unter registry.modelcontextprotocol.io, das zentrale Metadaten-Repository für öffentlich zugängliche Server, getragen von Anthropic, GitHub, Microsoft und PulseMCP. Sie ist quelloffen, unterstützt Unter-Registries und befindet sich vor der allgemeinen Verfügbarkeit weiterhin in der Preview – rechnen Sie also mit Veränderungen.
2. 02Clientseitige Verzeichnisse wie das Connectors-Verzeichnis von Claude und das App-Verzeichnis von ChatGPT, jeweils mit einem eigenen Prüfprozess.
3. 03Ihre eigene Dokumentation. So kommen die meisten Verbindungen heute tatsächlich zustande: Eine Entwicklerseite nennt die Endpunkt-URL, die Tool-Liste und die Autorisierungs-Scopes, und ein Kunde fügt sie in seinen Client ein.

Veröffentlichen Sie Ihr .well-known/oauth-protected-resource-Dokument auch dann, wenn die meisten Tools öffentlich sind, und versionieren Sie den Endpunktpfad. Sie werden Ihre Tool-Oberfläche verändern, und das sollte eine bewusste Migration sein und kein stiller Bruch.

Eine Checkliste für die Umsetzung

1. 01Führen Sie alles auf einen kanonischen Datensatz je Teil zusammen – mit typisierten Attributen, Einheiten, Herkunft und einem Zeitstempel der letzten Verifizierung. Beginnen Sie nicht mit dem Protokoll.
2. 02Wählen Sie sechs bis acht Tools und schreiben Sie Beschreibungen, die auch sagen, wann ein Tool nicht zu verwenden ist.
3. 03Deklarieren Sie Output-Schemas und geben Sie structuredContent zurück. Nehmen Sie Einheiten und Verifizierungsdaten in jede Payload auf.
4. 04Betreiben Sie einen einzigen POST-Endpunkt, der die Header Mcp-Method und Mcp-Name berücksichtigt, Origin validiert und bei List-Ergebnissen ttlMs und cacheScope setzt.
5. 05Trennen Sie öffentliche und geschützte Tools, implementieren Sie die Metadaten nach RFC 9728, validieren Sie die Token-Audience gemäß RFC 8707 und nutzen Sie Scope-Anforderungen, um in einem einzigen Roundtrip nachzuautorisieren.
6. 06Geben Sie eine deterministische Tool-Reihenfolge und stabile Tool-Namen zurück, damit Client-Caches funktionieren.
7. 07Protokollieren Sie jeden Aufruf – Tool, Argumente, Latenz und ob die Abfrage aufgelöst werden konnte. Ein MCP-Server ohne Analytics ist ein Kanal, den Sie nicht steuern können.
8. 08Überwachen Sie die Genauigkeit gegen die Referenzdaten, und zwar fortlaufend. Ein Tool, das souverän einen veralteten Kennwert zurückgibt, ist schlimmer als gar kein Tool.

Partsgraph liefert das als Managed Layer: Wir führen Ihren bestehenden Katalog zu einem verifizierten Parts Graph zusammen, hosten den MCP-Endpunkt mit OAuth auf den geschützten Ebenen und berichten, welche Agenten was aufgerufen haben und wo die Antworten falsch waren.

Wenn Sie wissen möchten, wo Sie stehen, bevor Sie eine Zeile Code schreiben, prüfen Sie Ihre Domain mit dem kostenlosen Grader unter /audit – er zeigt, was Maschinen aktuell in Ihrem Katalog erreichen können und ob ein MCP-Endpunkt überhaupt etwas Vertrauenswürdiges auszuliefern hätte.