Einen Multi-Vendor-Marketplace-Katalog für KI-Shopping-Agenten lesbar machen: Schema, Feeds und Tool-Interfaces

Dieser Leitfaden richtet sich an CTOs, Architekten und Product Owner eines Multi-Vendor-Marketplaces, die bereits über die Architektur der Plattform entschieden und das Seller-Onboarding sequenziert haben und nun dafür sorgen müssen, dass der resultierende Katalog von einem KI-Shopping-Agenten gelesen, verglichen und für Transaktionen genutzt werden kann. Die E-Commerce-Entwicklung ist der Bereich, in dem diese Arbeit nach abgeschlossenem Design stattfindet, auf Basis der E-Commerce-Marketplace-Lösung. Für die Agenten-Readiness eines Einzelhändler-Shops siehe unseren separaten Leitfaden zur Agentic Commerce Readiness; dieser hier ist auf das ausgerichtet, was sich ändert, wenn der Katalog die Angebote vieler Anbieter statt eines einzigen Händlers enthält.

In diesem Leitfaden

• Warum funktioniert ein Einzelhändler-Produktschema nicht für einen Multi-Vendor-Katalog?
• Schema-Modell: ein Produkt, viele Anbieter-Angebote
• Vendor-Feeds zu einem agenten-lesbaren Katalog-Feed normalisieren
• Was muss das Tool-Interface eines Marketplaces bereitstellen, das ein Einzelhändler-Shop nicht bereitstellt?
• Wo KI in einem Multi-Vendor-Katalog zum Einsatz kommt
• Welche Liefernachweise existieren und welche nicht
• Alternativen: Wer die Schema-, Feed- und Tool-Interface-Schicht aufbaut und betreibt
• Grenzen dieses Leitfadens
• Häufig gestellte Fragen
• Nächster Schritt

Warum funktioniert ein Einzelhändler-Produktschema nicht für einen Multi-Vendor-Katalog?

Ein Einzelhändler-Shop veröffentlicht ein Product mit einem Offer: ein Preis, eine Lageranzahl, ein Verkäufer, eine Richtlinie, alles implizit dem Händler selbst zugehörig. Ein Marketplace-Katalog hat häufig mehrere Anbieter, die im Wesentlichen dasselbe Produkt verkaufen, und ein Agent, der diese vergleicht, muss nicht nur den niedrigsten Preis kennen, sondern auch, welchem Anbieter dieser Preis gehört, welchen Lagerbestand, welche Versand- und Rückgaberichtlinien dieser Anbieter hat und wie eine Bestellung an den richtigen Verkäufer weitergeleitet wird. Diese anbieterspezifischen Informationen in eine Zusammenfassung zu komprimieren beantwortet zwar die Frage nach der Preisspanne, aber nicht die Frage nach dem Anbieter und den Konditionen, und genau diese Frage muss ein Agent beantworten können, bevor er handeln kann.

Schema-Modell: ein Produkt, viele Anbieter-Angebote

Die praktische Regel: AggregateOffer für eine menschlich lesbare Zusammenfassung (niedrigster Preis und Verkäuferanzahl) verwenden, falls eine Seite das benötigt, und einem agenten-gerichteten Feed oder einer API das darunter liegende anbieterspezifische Offer-Array mit einer stabilen Verkäufer-ID auf jedem Eintrag bereitstellen. Googles eigene Leitlinien für Multi-Seller-Marketplaces vertreten dieselbe Position auf Feed-Ebene: Ein Marketplace-Konto muss für jedes Element eine external_seller_id setzen, damit jeder Verkäufer über Updates hinweg identifizierbar bleibt (Google Merchant Center, Produktdatenspezifikation, abgerufen 2026-10-26).

Was muss das Tool-Interface eines Marketplaces bereitstellen, das ein Einzelhändler-Shop nicht bereitstellt?

Ein MCP- oder protokollbasiertes Tool-Interface eines Einzelhändler-Shops kann davon ausgehen, dass jede Antwort zum einen dahinterstehenden Händler gehört. Das Tool-Interface eines Marketplaces kann das nicht: Derselbe Such- oder Produkt-Lookup-Aufruf kann für ein Produkt mehrere Anbieter zurückgeben, und jedes Ergebnis benötigt seinen eigenen Preis, Lagerbestand, eigene Richtlinien und die Verkäuferidentität, nicht geerbt vom Katalog. Das Interface braucht außerdem eine Möglichkeit, plattformseitige Regeln (zum Beispiel das eigene Rückgabefenster des Marketplaces für Streitfälle) separat von der Richtlinie eines Anbieters auszudrücken, da beide voneinander abweichen können und ein Agent wissen muss, welche für ein bestimmtes Angebot gilt. Anthropics Model Context Protocol beschreibt dies als Unterschied zwischen einem Tool-Aufruf (einer Aktion, etwa eine Bestellung bei einem bestimmten Verkäufer aufgeben) und einer Resource (Daten, die ein Client liest, etwa ein Katalog-Listing), was sich sauber auf einen Marketplace übertragen lässt: Katalog- und Angebotsdaten sind Resources, die über viele Anbieter hinweg gelesen werden, während Checkout ein Tool-Aufruf ist, der auf die Bestellung eines Anbieters beschränkt ist (Model Context Protocol, Spezifikation, abgerufen 2026-10-26). Shopify und Googles Universal Commerce Protocol verfolgen auf Katalog-Ebene einen vergleichbaren Ansatz: Katalog- und Checkout-Fähigkeiten werden veröffentlicht, die ein Agent entdecken kann, statt Daten eines einzelnen Händlers vorauszusetzen (Shopify Engineering, Universal Commerce Protocol, abgerufen 2026-10-26).

Welche Liefernachweise existieren und welche nicht

• RB Marketplace. Der RB-Marketplace-Datensatz beschreibt einen live betriebenen Multi-Vendor-Marketplace mit einer Kunden-REST-API und einer mobilen App, die auf derselben API aufbaut, und demonstriert damit einen API-first-Katalog, den ein externer Client bereits liest; kein KI-gestützter Normalisierungsschritt, kein Structured-Data-Schema und keine Agenten-/MCP-Integration sind beschrieben, und es ist keine Kataloggröße oder Leistungskennzahl veröffentlicht.
• Commerce-Plattform-Portfolio. Netbase JSC hat Commerce-Lösungen auf WooCommerce, Magento 2, Laravel und headless commerce geliefert und arbeitet mit PrestaShop, OpenCart, Shopware, CS-Cart, Shopify, Salesforce, Akeneo, Odoo und Symfony (den Plattformen, auf denen eine Katalog- und Feed-Schicht in diesem Leitfaden aufsitzen oder mit denen sie integriert werden würde).
• Investitionsrichtung. David (CEO) hat Agentic Commerce und API-first-Delivery als Investitionsbereiche über alle Services von Netbase JSC hinweg genannt, neben der in die Delivery verwobenen KI-Transformation; dies ist eine erklärte Richtung, kein ausgeliefertes Agenten-Katalog-Feature.

Was nicht existiert. Kein veröffentlichter Datensatz von Netbase JSC beschreibt ein Multi-Vendor-Katalog-Schema, das speziell für KI-Shopping-Agenten entwickelt wurde, einen normalisierten agenten-gerichteten Feed oder eine MCP/UCP/ACP-Tool-Interface-Integration. Das obige Framework ist eine Liefermethode, die auf schema.org-, Google-Merchant-Center- und Model-Context-Protocol-Dokumentation sowie auf der Struktur der eigenen Multi-Vendor-Katalog- und API-Arbeit von Netbase JSC aufbaut, kein gemessenes Agenten-Readiness-Projekt.

Alternativen: Wer die Schema-, Feed- und Tool-Interface-Schicht aufbaut und betreibt

In der individuellen Entwicklung durch Netbase JSC gehört das für den Kunden erstellte IP dem Kunden, und die meisten Projekte laufen auf Festpreisverträgen, die nach der Discovery vereinbart werden; daneben werden meilensteinbasierte, monatliche Team-Retainer- und KPI-gebundene Konditionen angeboten. Behandeln Sie einen Agenten oder Tool-Interface-Aufrufer als neuen Client-Typ auf der API: Netbase JSCs Standard-Sicherheitspraktiken, rollenbasierte Zugriffskontrolle, MFA auf Admin-Dashboards, TLS während der Übertragung und Verschlüsselung im Ruhezustand, gelten für eine Katalog-API, die externe Aufrufer bedient, nicht nur für die Storefront. Das Angebot liegt in der E-Commerce-Entwicklung, für die E-Commerce-Marketplace-Lösung, relevant für Einzelhandel und E-Commerce-Marketplaces.

Grenzen dieses Leitfadens

• Die Dokumentation von Schema.org, Google Merchant Center und Model Context Protocol ändert sich; prüfen Sie aktuelle Felder und Anforderungen bei den jeweiligen Herausgebern, bevor Sie darauf aufbauen.
• Es wird keine Kataloggröße, Matching-Genauigkeit oder Agenten-Bestell-Kennzahl beansprucht; Netbase JSC veröffentlicht für diese Arbeit heute keine derartigen Werte.
• Dieser Leitfaden behandelt nur Katalog-Schema, Feed-Normalisierung und das Tool-/API-Interface; das Seller-Intake wird in einem separaten Leitfaden behandelt, und die Readiness eines Einzelhändler-Shops in Agentic Commerce Readiness.

Nächster Schritt

Teilen Sie uns mit, wie Ihre Anbieter derzeit Produktdaten liefern, und wir vereinbaren einen Solution Review, um ein Multi-Vendor-Schema, einen Feed und ein Tool-Interface-Design zu skizzieren. Sie können auch unseren Leitfaden zur Marketplace-Plattformarchitektur lesen oder weitere Netbase-Insights durchstöbern.

Verwandte Leistungen und Lösungen