# MCP für Hersteller: Ein Praxisleitfaden

> Was das Model Context Protocol ist, was ein Teile-MCP-Server bereitstellen sollte, wie OAuth Preis und Bestand absichert und welche Assistenten ihn erreichen.

**Language:** de  
**Published:** 2026-08-09  
**Category:** Technical · **Tags:** MCP, Model Context Protocol, OAuth, Streamable HTTP, parts data, AI agents  
**Canonical:** https://partsgraph.ai/de/blog/mcp-for-manufacturers

## Kurz gefasst

**Was ist MCP, und was sollte der MCP-Server eines Herstellers bereitstellen?**

MCP (das Model Context Protocol) ist ein offener Standard, mit dem ein KI-Assistent Ihre Systeme direkt aufruft, statt Antworten aus Ihren Webseiten abzuleiten. Der MCP-Server eines Herstellers ist ein gehosteter HTTP-Endpunkt, der eine überschaubare Menge typisierter Tools bereitstellt – parametrische Suche, Artikelabfrage, Alternativen und Cross-Referenzen, Konformitätsdokumente, CAD-Links sowie per OAuth abgesicherte Bestands- und Preisdaten –, die jeder kompatible Assistent aufrufen kann, um eine exakte, prüfbare Antwort zu erhalten. Nach der aktuellen Spezifikation 2026-07-28 handelt es sich um einen zustandslosen Request/Response-Dienst, der hinter einem gewöhnlichen Load Balancer läuft. Das Protokoll ist der einfache Teil; schwierig ist es, dahinter einen einzigen kanonischen, verifizierten Produktdatensatz zu haben.

---

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

> **Figure.** Parsing forty pages versus one typed MCP tool call.

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.

| Änderung | Vorher | Ab 2026-07-28 |
| --- | --- | --- |
| Sitzungen | Header `Mcp-Session-Id`, vom Server vergeben | Entfallen; Zustand wird als explizite, vom Server ausgestellte Handles in Tool-Argumenten übergeben |
| Handshake | `initialize` / `notifications/initialized` | Entfallen; Protokollversion und Client-Capabilities reisen bei jeder Anfrage in `_meta` mit |
| Capability-Discovery | Beim Initialisieren ermittelt | Neuer `server/discover`-RPC, den Server implementieren **müssen** |
| Server-initiierte Anfragen | Über einen SSE-Stream gesendet | Multi Round-Trip Requests: Der Server liefert `resultType: "input_required"`, der Client wiederholt mit `inputResponses` |
| Routing | Gateways parsten den JSON-Body | Header `Mcp-Method` und `Mcp-Name` bei POST-Anfragen **erforderlich** |
| Caching | Nur `listChanged`-Benachrichtigungen | `ttlMs` und `cacheScope` bei List- und Read-Ergebnissen erforderlich |
| Stream-Wiederaufnahme | Wiedergabe über `Last-Event-ID` | Entfallen; ein abgebrochener Stream verliert die Anfrage, und der Client stellt sie erneut |

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. **Nicht authentifizierte Ebene** – Spezifikationen, parametrische Suche, Alternativen, Konformitätsdokumente, CAD-Links und Listenpreise, sofern Sie diese veröffentlichen.
2. **Authentifizierte 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. Setzen 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.

| Tool | Zweck | Auth |
| --- | --- | --- |
| `search_parts` | Parametrische Suche innerhalb einer Klasse mit typisierten Constraints und Einheiten | Öffentlich |
| `get_part` | Vollständiger kanonischer Datensatz zu einer Artikelnummer, inklusive Herkunft und Datum der letzten Verifizierung | Öffentlich |
| `find_alternates` | Funktionale Äquivalente, Zweitquellen und Wettbewerbs-Cross-Referenzen mit angegebener Äquivalenzgrundlage | Öffentlich |
| `get_compliance_documents` | RoHS, REACH, Leistungserklärungen, Zertifikate, EPDs – als Datensätze mit Ausstellungsdatum, nicht nur als Links | Öffentlich |
| `get_cad_models` | Resource-Links auf 2D-, 3D- und BIM-Assets nach Format | Öffentlich |
| `get_availability` | Live-Bestand nach Standort und Lieferzeit | Geschützt |
| `get_price` | Kundenvertragspreise nach Menge | Geschützt |

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

```json
{
  "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.

```text
→ 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.

| Client | Erreicht er einen eigenen MCP-Server? | Bedingungen |
| --- | --- | --- |
| Claude | Ja | Eigene Remote-Connectors in Free, Pro, Max, Team und Enterprise; Free-Nutzer auf einen begrenzt; der Server muss aus den IP-Bereichen von Anthropic über das öffentliche Internet erreichbar sein |
| ChatGPT | Teilweise | Eigene MCP-Server über den Entwicklermodus; schreibfähige Connectors auf Business, Enterprise und Edu beschränkt, Plus und Pro nur lesend. Apps in ChatGPT basieren auf MCP und durchlaufen eine Verzeichnisprüfung |
| Gemini | Nur Enterprise | Eigene MCP-Server, die ein Administrator in Gemini Enterprise als Datenspeicher registriert; ausschließlich Streamable-HTTP-Transport |
| Microsoft Copilot | Ja, in Enterprise-Konfigurationen | Vom Administrator registrierte Connectors |
| IDE- und CLI-Agenten | Ja | Der Entwickler konfiguriert den Endpunkt direkt – der reibungsärmste Weg für ein Ingenieurspublikum |
| Eigene Agenten Ihrer Kunden | Ja | Einkaufs- und Entwicklungsabteilungen betreiben zunehmend interne Agenten; in der Praxis ist das die am schnellsten wachsende Aufrufergruppe |

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. **Die 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. **Clientseitige Verzeichnisse** wie das Connectors-Verzeichnis von Claude und das App-Verzeichnis von ChatGPT, jeweils mit einem eigenen Prüfprozess.
3. **Ihre 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. **Fü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. **Wählen Sie sechs bis acht Tools** und schreiben Sie Beschreibungen, die auch sagen, wann ein Tool *nicht* zu verwenden ist.
3. **Deklarieren Sie Output-Schemas** und geben Sie `structuredContent` zurück. Nehmen Sie Einheiten und Verifizierungsdaten in jede Payload auf.
4. **Betreiben 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. **Trennen 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. **Geben Sie eine deterministische Tool-Reihenfolge** und stabile Tool-Namen zurück, damit Client-Caches funktionieren.
7. **Protokollieren 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. **Ü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](/audit) – er zeigt, was Maschinen aktuell in Ihrem Katalog erreichen können und ob ein MCP-Endpunkt überhaupt etwas Vertrauenswürdiges auszuliefern hätte.

## Häufige Fragen

### Brauchen wir MCP, wenn wir bereits eine REST-API haben?

Ihre REST-API ist die richtige Grundlage, aber ein Agent kann sie nicht nutzen, ohne dass derjenige, der den Agenten betreibt, eine maßgeschneiderte Integration baut. MCP standardisiert drei Dinge, die eine REST-API offenlässt: wie ein Client herausfindet, welche Operationen existieren, wie deren Ein- und Ausgaben für ein Modell typisiert sind und wie die Autorisierung ausgehandelt wird. In der Praxis ist ein Teile-MCP-Server eine schlanke, bewusst zugeschnittene Projektion einer bestehenden API, deren Schemas und Beschreibungen für ein Modell und nicht für einen Entwickler geschrieben sind.

### Sollten Teiledaten als Tools oder als Resources bereitgestellt werden?

Überwiegend als Tools. Die Spezifikation beschreibt Tools als modellgesteuert – das Modell entdeckt und ruft sie aus dem Kontext heraus auf –, während Resources anwendungsgesteuert sind und von der Host-Anwendung zur Auswahl durch den Nutzer angeboten werden. Ein Katalog ist ein Abfrageraum und keine feste Dateiliste; die natürliche Entsprechung sind daher Tools, die Parameter entgegennehmen. Resources rechtfertigen sich für eine kleine Zahl stabiler Dokumente, und Tools können Resource-Links auf Datenblätter und CAD-Dateien zurückgeben, statt Megabytes inline mitzuliefern.

### Bricht die Spezifikation 2026-07-28 bestehende MCP-Server?

Sie verändert die Form des Transports erheblich. Sitzungen auf Protokollebene und der Header Mcp-Session-Id sind entfallen, der initialize-Handshake ist entfallen, der eigenständige GET-Stream ist entfallen, und die SSE-Wiederaufnahme über Last-Event-ID ist entfallen. Server müssen server/discover implementieren und bei POST-Anfragen die Header Mcp-Method und Mcp-Name verlangen. Clients, die beide Generationen unterstützen, erkennen die Variante eines Servers, indem sie zunächst eine moderne Anfrage versuchen und den Fehlerkörper auswerten, bevor sie zurückfallen.

### Wie verhindern wir, dass ein Agent die Preise eines anderen Kunden sieht?

Über die Autorisierungsebene, nicht über Verschleierung. Der MCP-Server fungiert als OAuth-2.1-Resource-Server, muss Protected Resource Metadata (RFC 9728) implementieren und muss prüfen, dass Access Tokens gemäß RFC 8707 ausdrücklich für ihn als vorgesehene Audience ausgestellt wurden. Entscheidend ist: Die Spezifikation erlaubt, dass die sichtbaren Tool- und Resource-Mengen je nach der mit der Anfrage vorgelegten Autorisierung variieren. Einem nicht authentifizierten Aufrufer lassen sich damit ausschließlich die öffentlichen Katalog-Tools zeigen.

### Wie findet ein Agent unseren MCP-Server überhaupt?

Einen Discovery-Mechanismus auf DNS-Ebene gibt es nicht, und das Gegenteil zu behaupten ist der häufigste Fehler in Texten über MCP. Auffindbarkeit entsteht über die offizielle MCP-Registry unter registry.modelcontextprotocol.io, die von Anthropic, GitHub, Microsoft und PulseMCP getragen wird und sich vor der allgemeinen Verfügbarkeit weiterhin in der Preview befindet; über clientseitige Verzeichnisse wie das Connectors-Verzeichnis von Claude und das App-Verzeichnis von ChatGPT; und heute am häufigsten schlicht dadurch, dass Sie die URL in Ihrer Entwicklerdokumentation veröffentlicht haben und ein Kunde sie dort eingefügt hat.

### Was ist der größte Designfehler bei einem ersten Teile-MCP-Server?

Zu viele Tools mit vagen Beschreibungen bereitzustellen. Ein Modell wählt Tools anhand ihrer Namen, Beschreibungen und Schemas aus; zwanzig sich überschneidende Suchendpunkte führen deshalb zu schlechterem Verhalten als sechs gut benannte. Geben Sie strukturierte Inhalte gegen ein deklariertes Output-Schema zurück, halten Sie Tool-Namen deterministisch und stabil und legen Sie Einheiten, Toleranzen und einen Zeitstempel der letzten Verifizierung in die Payload, damit die Antwort später prüfbar bleibt.

### Hilft ein MCP-Server bei der KI-Sichtbarkeit im offenen Web?

Nicht direkt. Such- und Retrieval-Crawler rufen keine MCP-Server auf, sie holen sich HTML. MCP erreicht Nutzer, die Ihren Server verbunden haben – heute also Ingenieure, die einen Connector einrichten, und Enterprise-Einkäufer, deren Administrator ihn registriert. Es ist ein Kanal für Tiefe, nicht für Reichweite, und er entfaltet seine Wirkung am besten neben serverseitig gerenderten, strukturierten Produktseiten.

## Quellen

1. [Anthropic, Introducing the Model Context Protocol (25 November 2024)](https://www.anthropic.com/news/model-context-protocol)
2. [Model Context Protocol, MCP joins the Agentic AI Foundation (9 December 2025)](https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/)
3. [Linux Foundation, Formation of the Agentic AI Foundation (9 December 2025)](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation)
4. [Model Context Protocol, 2026-07-28 specification changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog)
5. [Model Context Protocol, Streamable HTTP transport (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http)
6. [Model Context Protocol, Authorization (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)
7. [Model Context Protocol, Tools (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)
8. [Model Context Protocol, Resources (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/server/resources)
9. [Model Context Protocol, The MCP Registry](https://modelcontextprotocol.io/registry/about)
10. [Microchip Technology, Microchip unveils Model Context Protocol (MCP) Server (6 November 2025)](https://ir.microchip.com/news-events/press-releases/detail/1344/microchip-technology-unveils-model-context-protocol-mcp-server-to-power-ai-driven-product-data-access)
11. [Siemens MCP Server documentation](https://mcp.siemens.com/docs)
12. [Zoovu, Zoovu launches MCP Server (11 December 2025)](https://zoovu.com/news/zoovu-launches-mcp-server)
13. [ECIA, TrustedParts.com launches Inventory AI Agent Service (11 June 2026)](https://www.ecianow.org/2026/06/11/trustedparts-com-launches-inventory-ai-agent-service/)
14. [Shopify, Storefront MCP server documentation](https://shopify.dev/docs/apps/build/storefront-mcp/servers/storefront)
15. [Anthropic, Get started with custom connectors using remote MCP](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp)
16. [OpenAI Help Center, Developer mode and MCP apps in ChatGPT](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt)
17. [Google Cloud, Set up your custom MCP server data store (Gemini Enterprise)](https://docs.cloud.google.com/gemini/enterprise/docs/connectors/custom-mcp-server/set-up-custom-mcp-server)

## Other languages

- English: https://partsgraph.ai/blog/mcp-for-manufacturers/md
- Français: https://partsgraph.ai/fr/blog/mcp-for-manufacturers/md
- Español: https://partsgraph.ai/es/blog/mcp-for-manufacturers/md
- Italiano: https://partsgraph.ai/it/blog/mcp-for-manufacturers/md
- Nederlands: https://partsgraph.ai/nl/blog/mcp-for-manufacturers/md
- Polski: https://partsgraph.ai/pl/blog/mcp-for-manufacturers/md
- Português: https://partsgraph.ai/pt/blog/mcp-for-manufacturers/md
- Svenska: https://partsgraph.ai/sv/blog/mcp-for-manufacturers/md
- Türkçe: https://partsgraph.ai/tr/blog/mcp-for-manufacturers/md
- 日本語: https://partsgraph.ai/ja/blog/mcp-for-manufacturers/md
- 한국어: https://partsgraph.ai/ko/blog/mcp-for-manufacturers/md
- 简体中文: https://partsgraph.ai/zh/blog/mcp-for-manufacturers/md

---

Partsgraph — the agent-ready parts data layer. Free AI-visibility grader: https://partsgraph.ai/de/audit