Connectors

Einen KI-Agenten mit Brightpearl verbinden: Wenn es keinen First-Party-MCP-Server gibt

Von IdeaBosqueZuletzt aktualisiert: 2026年7月22日

Kernpunkte

Null First-Party-MCP-Abdeckung — Brightpearl hat keinen vom Anbieter gelieferten MCP-Server für Store-Operationen, anders als NetSuite (AI Connector), Shopify (Storefront MCP + UCP) und HubSpot (Remote MCP Server). Das Custom-Modul ist die Integration, kein Lückenfüller.
200 Anfragen pro rollierendem 60-Sekunden-Fenster, HTTP 503 bei Überschreitung — das Throttling der Brightpearl REST-API. Private Apps teilen sich einen Pool pro Konto. Keine gestaffelten Caps, keine Pläne zur Erhöhung. Ein Agent mit 30 parallelen Tool-Aufrufen kann das Fenster in Sekunden erschöpfen.
76 Daten-Endpunkte über den Third-Party-SyncHub-MCP verfügbar, aber nur lesend — der einzige Managed-MCP-Server für Brightpearl ist SyncHub, der Daten in ein Azure-Warehouse synchronisiert und als nur-lesende MCP-Oberfläche bereitstellt. Kein Write-Back, keine Auftragserstellung, keine Bestandsaktualisierungen.
B2B-Preislisten pro Kundengruppe zugewiesen — die semantische Schicht, die kein Wrapper kodiert — Brightpearls Großhandelspreismodell (Preislisten pro Konto, Gruppe oder Verkäufer) ist die geschäftliche Bedeutung, die ein generischer API-Wrapper nicht ableiten kann. Welche Preisliste für welchen Kontakt für welches Produkt gilt, ist eine semantische-Schicht-Entscheidung, kein Datenabruf.
Anthropics 2026 State of AI Agents Report identifiziert Integration als #1 Adoptionsbarriere bei 46% — für Brightpearl-Händler ist die Barriere nicht eine Lücke in einem First-Party-Server. Es ist das Fehlen eines solchen Servers.

Das Problem: kein vom Anbieter gelieferter Agent-Einstiegspunkt

Der 2026 State of AI Agents Report von Anthropic befragte 500+ technische Führungskräfte mit realen Implementierungen bei Novo Nordisk, Doctolib, L'Oréal und Shopify. Integration ist die #1 Adoptionsbarriere bei 46%. Für einen Brightpearl-Händler hat diese Barriere eine konkrete Form: es gibt keinen First-Party-MCP-Server zur Integration.

Die Konnektor-Reihe hat bisher vier Anbieter kartografiert. NetSuite lieferte einen AI Connector Service mit einem MCP-Endpunkt — das Custom-Modul füllt die semantische-Schicht-Lücke (welche GL-Konten "Umsatz" sind). Shopify lieferte einen Storefront-MCP-Server und co-entwickelte das Universal Commerce Protocol mit Google — das Custom-Modul füllt die B2B-Lücke (Kunden-Tier-Preisgestaltung, Bulk-RFQ-Quotierung). HubSpot lieferte einen Remote MCP Server mit 12 Tools — das Custom-Modul füllt sechs Fähigkeitslücken (Custom Objects, prüfbare Schreibvorgänge, Headless-Auth). BigCommerce kooperierte mit Stripe auf der Agentic Commerce Suite — das Custom-Modul füllt die B2B Price List- und Customer Group-Lücke.

Brightpearl ist der fünfte Fall, und das Muster ist anders. Brightpearl ist ein Retail Operating System für Mid-Market-Retail- und Großhandelsmarken mit 1–20 M$ Umsatz. Es ist ein Shopify Global ERP Program-Partner mit nativer Shopify-Integration — Bestandsaktualisierungen in Sekunden, automatisches Bestell-Routing, einheitliche Kundenhistorie. Es hat eine REST-API, die identisch mit der von Brightpearls eigenen Entwicklern genutzten ist und Aufträge, Produkte, Kontakte, Bestand, Buchhaltung und Warehouse-Operationen abdeckt. Was es nicht hat, ist ein MCP-Server. Kein Storefront MCP, kein AI Connector, kein Remote MCP Server, kein Docs-only MCP. Der Anbieter hat keinen Agent-Einstiegspunkt geliefert.

Dieser Artikel kartografiert die drei existierenden Agent-Integrationspfade, die semantische-Schicht-Lücken in jedem und das Custom-MCP-Modul-Muster, das Brightpearl agent-ready macht. Das Framing unterscheidet sich von früheren Konnektor-Artikeln: hier ist das Custom-Modul keine Ergänzung zu einem First-Party-Server. Es ist die Integration.

Die drei Agent-Integrationspfade

Pfad 1: SyncHub — nur-lesender MCP ohne Write-Back

SyncHub bietet einen Plug-and-Play-MCP-Server, der Brightpearl-Daten mit KI-Chatbots verbindet. Er synchronisiert inkrementell Daten von 76 Brightpearl-Endpunkten in eine KI-optimierte Datenbank, die in Microsoft Azure (Sydney-Rechenzentrum) gehostet wird, und verpackt diese Datenbank dann in eine MCP-konforme Schnittstelle. Der Agent fragt die synchronisierten Daten über natürliche Sprache ab, und SyncHubs SQL-Generierungs-Engine gibt nur die benötigten Zeilen zurück — was den Token-Verbrauch reduziert. Er unterstützt 70+ Konnektoren über Brightpearl hinaus, sodass ein Händler, der Brightpearl plus Shopify plus Xero betreibt, alle drei in einer einzigen Konversation abfragen kann.

Die Einschränkung ist strukturell: SyncHub ist nur lesend. Das FAQ sagt es klar: "Brightpearl aktualisieren? Nein — SyncHub ist nur lesend." Ein Agent, der einen Verkaufsauftrag erstellen, Bestandsstände aktualisieren, einen Kundendatensatz ändern oder eine Zahlung erfassen muss, kann dies nicht über SyncHub tun. Die MCP-Oberfläche ist eine Abfrage-Schicht, keine Aktions-Schicht. Für Analyse- und Reporting-Anwendungsfälle — "zeige mir überfällige Forderungen über alle Kanäle" oder "welche Lieferanten lieferten die höchsten Margen im letzten Quartal" — ist SyncHub ein echtes Produkt. Für einen Agenten, der Quotierungs-Workflows orchestriert, RFQs verarbeitet oder Auftragserfüllung automatisiert, ist es nicht der Integrationspfad.

Pfad 2: Composio / Rube MCP — generischer Wrapper ohne B2B-semantische Schicht

Der zweite Pfad ist ein generischer API-Wrapper. Composios Rube MCP bietet ein Claude-Code-Skill, das die Brightpearl REST-API für Auftragsverwaltung, Bestandssynchronisation und Kundendatensatz-Updates wrappt. Es unterstützt Massenoperationen über RUBE_REMOTE_WORKBENCH, umfasst Fehlerbehandlung und Paginierungsverwaltung und nutzt dynamische Tool-Entdeckung über RUBE_SEARCH_TOOLS für Echtzeit-Schema-Compliance. Dieser Pfad kann lesen und schreiben — er wrappt die rohe API, sodass jeder Endpunkt, den die API bereitstellt, erreichbar ist.

Die Einschränkung ist die semantische Schicht. Ein generischer Wrapper stellt API-Endpunkte als Tools bereit, kodiert aber keine geschäftliche Bedeutung. Brightpearls Preislistensystem weist Preise pro Kontakt, Kontaktgruppe oder Verkäufer zu — ein B2B-Preismodell, bei dem dasselbe Produkt basierend auf ausgehandelten Vertragsbedingungen für jedes Großhandelskonto einen anderen Preis trägt. Die API gibt alle Preislisten zurück; der Agent weiß nicht, welche für den aktuellen Kunden für das aktuelle Produkt unter den aktuellen Vertragsbedingungen gilt. Diese Entscheidung ist eine semantische-Schicht-Operation: die Kontaktgruppe des Kunden auflösen, die dieser Gruppe zugewiesene Preisliste nachschlagen, nach Produkt und Mengenstaffel filtern und den Vertragspreis zurückgeben. Ein generischer Wrapper gibt die rohen Preislistendaten zurück und überlässt die Auflösung dem Modell — was genau dort ist, wo Halluzinationsrisiko entsteht. Der MCP Module Code Standard nennt dies "typisierte Schemas, die geschäftliche Bedeutung kodieren." Der Wrapper hat Typen. Er hat keine Bedeutung.

Pfad 3: Custom-MCP-Modul — die Integration

Der dritte Pfad ist ein Custom-MCP-Modul, das direkt gegen die Brightpearl REST-API gebaut ist. Dies ist dasselbe Strukturmuster wie die NetSuite-, Shopify- und HubSpot-Module — aber mit einer anderen Arbeitsverteilung. In diesen Fällen ergänzt das Custom-Modul einen First-Party-Server: der Anbieter handhabt die Verbindung, das Modul handhabt die Semantik. Im Fall von Brightpearl handhabt das Custom-Modul beides. Es ist die Integration.

Das Modul-Muster folgt dem MCP Module Code Standard: jedes Tool hat ein typisiertes Eingabe-Schema, ein typisiertes Ausgabe-Schema, ein Rate-Limit, ein Audit-Log und einen Fehler-Vertrag. Der Agent ruft Tools namentlich mit strukturierten Argumenten auf, nicht freie API-Aufrufe gegen rohe Endpunkte. Das Modul kodiert die semantische Schicht — welche Preisliste für welchen Kunden gilt, welcher Auftragsstatus Warehouse-Routing auslöst, welcher Nomenklaturcode auf Umsatz mappt — als typisierte Schemas, die das Modell nicht ableiten muss.

Die API-Oberfläche: ressourcenorientiertes REST mit striktem Throttling

Brightpearls API ist eine saubere, ressourcenorientierte REST-Oberfläche. Die API-Fundamentals-Dokumentation ist explizit über die Designphilosophie: Ressourcen, nicht Methoden. Eine Ressource ist jede Entität, die Brightpearl verwaltet — Kontakte, Aufträge, Produkte, Warehouses, Nomenklaturcodes, Preislisten. Verhalten wird über HTTP-Verben gesteuert: POST erstellt, PUT/PATCH modifiziert, GET liest, DELETE löscht. JSON für allen Datenaustausch. Die API ist dieselbe, die Brightpearls eigene Entwickler nutzen — neue Funktionen werden über dieselbe Oberfläche geliefert, die Integratoren erhalten.

Das Anfragen-Throttling ist die Produktions-Einschränkung, die das Modul-Design prägt. Die Obergrenze ist 200 Anfragen pro rollierendem 60-Sekunden-Fenster. Private Apps, die mit einem Konto verbunden sind, teilen sich einen Pool — mehrere private Apps können sich gegenseitig drosseln. Öffentliche Apps erhalten einen separaten Pool pro Konto/Entwickler-Kombination. Wenn die Obergrenze erreicht ist, erhalten nachfolgende Anfragen HTTP-503-"Too Busy"-Antworten, und die Anfragen werden verworfen — nicht in eine Warteschlange gestellt. Die Antwort-Header brightpearl-requests-remaining und brightpearl-next-throttle-period teilen dem Aufrufer mit, wie viele Anfragen übrig sind und wann das Fenster zurückgesetzt wird. Es gibt keine gestaffelten Caps und keine Pläne, das Limit zu erhöhen.

Für einen Agenten, der 30 parallele Tool-Aufrufe während eines Quotierungs-Workflows ausführt — Kunde abrufen, Produkt abrufen, Preisliste abrufen, Bestand abrufen, Warehouse-Verfügbarkeit abrufen, Auftrag erstellen, Zahlung erfassen — kann das 200-Anfrage-Fenster in Sekunden erschöpft werden, wenn das Modul kein Tool-bezogenes Throttling erzwingt. Das Custom-Modul handhabt dies genauso wie das NetSuite-Modul seinen Concurrency-Pool handhabt: jeder Tool-Aufruf prüft die verbleibende Anfragezahl aus den Antwort-Headern, und das Modul erzwingt einen Mindestabstand von 0,3 Sekunden zwischen Aufrufen (60 Sekunden / 200 Anfragen = 0,3 Sekunden pro Anfrage). Der Agent sieht nie eine 503. Das Modul absorbiert das Throttling.

Authentifizierung: OAuth 2.0 mit 7-Tage-Tokens

Brightpearl nutzt OAuth 2.0 Authorization Code Grant für die API-Authentifizierung. Das Access-Token läuft nach 604.800 Sekunden — 7 Tagen — ab. Ein Refresh-Token wird zusammen mit dem Access-Token bereitgestellt und kann verwendet werden, um ein neues Access-Token zu erhalten, ohne den browserbasierten Consent-Flow erneut auszuführen. Jeder API-Aufruf enthält den Authorization: ***-Header plus die brightpearl-dev-ref- und brightpearl-app-ref`-Header, die Entwickler und Anwendung identifizieren.

Der 7-Tage-Ablauf ist Headless-freundlicher als HubSpots OAuth 2.1 + PKCE (Single-Use-Refresh-Tokens, die bei jedem Refresh rotieren), aber weniger Headless-freundlich als BigCommerces X-Auth-Token (Store-Scoped-Bearer-Tokens, die nicht ablaufen, außer sie werden widerrufen). Ein Hintergrund-Agent, der nächtliche Bestandssyncs oder geplante Auftragsverarbeitung ausführt, kann das Refresh-Token verwenden, um den Zugriff über Wochen aufrechtzuerhalten, solange das Modul den Refresh-Zyklus intern handhabt — Token-Ablauf vor jedem Aufruf prüfen, transparent refreshen und das Refresh-Ereignis im Audit-Trail protokollieren.

Der Private-App-Pfad ist das einfachere Authentifizierungsmodell für interne Integrationen. Eine private App wird im App Store des Brightpearl-Kontos erstellt, nutzt Personal-Anmeldedaten und erfordert nicht den vollständigen OAuth-Flow. Dies entspricht NetSuites Token-Based Authentication (TBA) — dem Produktionsstandard für unbeaufsichtigte Operationen. Das Custom-Modul unterstützt beide Pfade: OAuth 2.0 für öffentliche App-Integrationen, die mehrere Brightpearl-Konten bedienen, und Private-App-Anmeldedaten für Single-Konto-Headless-Agents.

Die B2B-semantische Schicht: Preislisten, Kundengruppen und die Bedeutungslücke

Brightpearls Großhandelsverwaltung-Fähigkeiten sind der zentrale Differenzierer, der ein Custom-Modul notwendig statt optional macht. Die Plattform unterstützt individuelle Preislisten pro Konto, Gruppe oder Verkäufer — ein B2B-Preismodell, bei dem dieselbe SKU basierend auf ausgehandelten Vertragsbedingungen für jeden Großhandelskunden einen anderen Preis trägt. Sie verarbeitet Proforma-Rechnungen, On-Account-Zahlungen, Anzahlungen und Teilzahlungen. Sie verwaltet Multi-Warehouse-Routing, Dropshipping, Teilerfüllung und Back-to-Back-Bestellungen über ihre Automation Engine.

Die semantische-Schicht-Lücke ist dasselbe strukturelle Muster, das in jedem Konnektor-Artikel erscheint, hat aber hier eine konkrete Form. Brightpearls Product-Price-Ressource gibt die Preise eines Produkts über alle Preislisten zurück. Die Price-List-Ressource gibt die Liste der Preislisten im System zurück. Die Contact-Ressource gibt die dem Kontakt zugewiesene Preisliste zurück. Aber die API löst nicht die Frage "was zahlt dieser spezifische Kunde für dieses spezifische Produkt in dieser spezifischen Menge?" — diese Auflösung erfordert die Verknüpfung der Preislisten-Zuweisung des Kontakts mit dem Preis des Produkts auf dieser Liste, gefiltert nach Mengenstaffel und Kanal. Ein generischer Wrapper gibt die rohen Daten zurück und überlässt die Verknüpfung dem Modell. Ein Custom-Modul kodiert die Verknüpfung als typisiertes Tool: get_contract_price(contact_id, product_id, quantity, channel_id) gibt eine einzelne Zahl mit einem Provenienz-Trail zurück, der zeigt, welche Preisliste, welche Staffel und welche Zuweisung sie erzeugt hat.

Dies ist dieselbe Lücke wie bei NetSuite (welche GL-Konten "Umsatz" sind), Shopify (welcher Preis für welches Kunden-Tier gilt) und HubSpot (welche Deal-Stufen in die Prognose einfließen). Die API des Anbieters stellt die Daten bereit. Die semantische Schicht — die geschäftliche Bedeutung, die Daten in eine Entscheidung verwandelt — ist, was das Custom-Modul kodiert. Der Unterschied bei Brightpearl ist, dass kein First-Party-Server existiert, um die einfache Hälfte zu handhaben. Das Custom-Modul handhabt beide Hälften.

Die Shopify-Verbindung: Brightpearl als ERP hinter dem Storefront

Brightpearls native Shopify-Integration ist vorgebaut und intern verwaltet — Bestandsaktualisierungen in Sekunden, automatisches Auftrags-Routing zu Warehouses, einheitliche Kundenhistorie kanalübergreifend. Brightpearl ist Shopify Global ERP Program-Partner, was bedeutet, dass die Integration Shopifys Performance- und User-Experience-Standards für den App Store erfüllt. Das Programm startete im Oktober 2021 und zielt auf Enterprise-Händler ab, die komplexe, voluminöse Retail-Geschäfte auf Shopify Plus betreiben.

Für die Agent-Orchestrierung erzeugt dies einen Zwei-System-Stack: Shopify handhabt den Storefront und die konsumentenorientierte Agent-Oberfläche (Storefront MCP, UCP), und Brightpearl handhabt die Back-Office-Operationen (Aufträge, Bestand, Buchhaltung, Warehouse-Routing). Das Custom-Brightpearl-MCP-Modul ist die Back-Office-Hälfte des Agent-Stacks. Ein Agent, der einen B2B-Auftrag über Shopifys UCP empfängt, kann an das Brightpearl-Modul für Bestandsreservierung, Preislisten-Auflösung, Auftragserstellung und Warehouse-Routing übergeben — ohne dass der Agent Brightpearls API-Oberfläche verstehen muss. Das Modul übersetzt zwischen der Commerce-Protokoll-Schicht (UCP/ACP) und der ERP-Ressourcen-Schicht (Brightpearl REST).

Brightpearl berichtet eine 97%ige Implementierungs-Erfolgsrate und eine durchschnittliche Go-Live-Zeit von 120 Tagen, verglichen mit einem Branchendurchschnitt von 420 Tagen für traditionelle ERPs. Für einen Mid-Market-Händler mit 1–20 M$ Umsatz zählt die Implementierungs-Ökonomie: Brightpearl bei 1.500–3.000 $ pro Monat mit einer 4–8-wöchigen Implementierung ist eine andere Kostenstruktur als NetSuite bei 5.000–15.000 $ pro Monat mit einer 8–20-wöchigen Implementierung. Die Agent-Integration folgt derselben Kurve — ein Custom-Brightpearl-MCP-Modul ist ein kleinerer Build als ein Custom-NetSuite-Modul, weil die API-Oberfläche kleiner und das Datenmodell meinungsstärker ist.