Einen KI-Agenten mit ShipStation verbinden: Was der rein dokumentationsbasierte MCP-Server nicht löst

Kernpunkte

• Erstanbieter-MCP ist rein dokumentationsbasiert — ShipStations offizieller MCP-Server unter docs.shipstation.com/mcp durchsucht API-Referenzmaterialien. Er hilft einem Agenten zu lernen, wie Endpunkte funktionieren. Er kann keine Bestellungen lesen, Etiketten erstellen, Bestände aktualisieren oder Sendungen stornieren. Dasselbe rein dokumentationsbasierte Muster wie bei BigCommerce.
• 40 Anfragen pro Minute auf V1, 200 auf V2 — die veraltete ShipStation V1-API (Basic Auth, Abschreibung vorgesehen) limitiert auf 40 Aufrufe pro Minute pro Schlüssel. Die aktuelle V2-API (ehemals ShipEngine) erlaubt 200. Ein Agent, der 30 parallele Werkzeugaufrufe gegen V1 durchführt, erschöpft das Fenster in Sekunden.
• Integrierter NetSuite-Connector kann keine benutzerdefinierten Felder mappen — die 200 $/Monat ShipStation-NetSuite-Integration unterstützt drei Workflow-Varianten, aber kein Mapping benutzerdefinierter Felder. Rabatte, Geschenknachrichten und spezielle Bearbeitungsanweisungen synchronisieren nicht. Drittanbieter-Connectors (Nova Module 400 $/Monat, Celigo) füllen die Lücke gegen Bezahlung.
• 45 verwaltete MCP-Aktionen über StackOne, aber keine B2B-Semantikebene — StackOnes ShipStation MCP-Server deckt Carrier, Bestellungen, Produkte, Lager, Stores, Etiketten, Fulfillments und Tags ab. Es ist ein generischer Wrapper. Keine Auflösung benutzerdefinierter Felder, kein ERP-Writeback mit semantischem Mapping, keine prüfbaren Schreibpläne.
• Anthropics Umfrage 2026 identifiziert Integration als die #1 Adoptionsbarriere bei 46% — für ShipStation-Händler, die NetSuite oder Brightpearl als ERP nutzen, ist die Barriere nicht die Verbindung. Es ist die Semantikebene zwischen Versanddaten und Finanzdatensätzen.

Das Problem: Dokumentation ist kein Betrieb

Der Anthropic 2026 State of AI Agents Report befragte über 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 ShipStation-Händler hat diese Barriere eine spezifische Form: Der Anbieter veröffentlichte einen MCP-Server, der einem Agenten die API beibringt, ihn aber nicht verwenden lässt.

Die Connector-Reihe hat bisher fünf Anbieter abgedeckt. NetSuite veröffentlichte einen AI Connector Service mit einem MCP-Endpunkt — das benutzerdefinierte Modul füllt die Lücke der Semantikebene (welche GL-Konten sind „Umsatz"). Shopify veröffentlichte einen Storefront MCP-Server und entwickelte gemeinsam mit Google das Universal Commerce Protocol — das benutzerdefinierte Modul füllt die B2B-Lücke (Kundenstufenpreise, Bulk-RFQ-Angebote). HubSpot veröffentlichte einen Remote MCP Server mit 12 Tools — das benutzerdefinierte Modul füllt sechs Fähigkeitslücken (benutzerdefinierte Objekte, prüfbare Schreibvorgänge, Headless-Authentifizierung). BigCommerce ging eine Partnerschaft mit Stripe für die Agentic Commerce Suite ein — das benutzerdefinierte Modul füllt die B2B Price List- und Customer Group-Lücke. Brightpearl veröffentlichte nichts — das benutzerdefinierte Modul ist die Integration selbst.

ShipStation ist der sechste Fall, und das Muster ist der Dokumentationspfad. ShipStation ist eine Multi-Carrier-Versandplattform, die von mittelständischen B2B- und E-Commerce-Händlern genutzt wird, um Carrier-Tarife zu vergleichen, Etiketten zu drucken und Sendungen über UPS, FedEx, USPS und DHL zu verfolgen. Sie hat eine V2-API (ehemals ShipEngine), die Tarifvergleich, Sendungen, Etiketten, Batch, Rücksendeetiketten, Manifeste, Abholungen, Produkte, Bestände, Lager und Standorte abdeckt. Sie veröffentlichte einen offiziellen MCP-Server — aber dieser Server bietet Zugang zu API-Dokumentation und Referenzmaterialien, nicht zu Store-Daten. Ein verbundener Agent kann lernen, wie der Sendungserstellungs-Endpunkt funktioniert. Er kann keine Sendung erstellen.

Dieser Artikel mappt die drei Agent-Integrationspfade, die existieren, die V1/V2-API-Aufteilung, die Ratenlimits und Langlebigkeit bestimmt, die Lücke bei benutzerdefinierten Feldern des NetSuite-Connectors und das Muster des benutzerdefinierten MCP-Moduls, das ShipStation agent-fertig für produktive B2B-Workflows macht.

Die drei Agent-Integrationspfade

Die ShipStation Agent-Integrationslandschaft teilt sich in drei Ebenen: Dokumentation (Erstanbieter), verwaltete Wrapper (Drittanbieter) und benutzerdefinierte Module (direkte V2-API).

Pfad 1: Dokumentationsbasierter MCP (Erstanbieter)

ShipStations offizieller MCP-Server befindet sich unter docs.shipstation.com/mcp und verbindet sich mit Claude Code, Cursor und VS Code. Die Dokumentation des Servers gibt die Einschränkung klar an: „Dieser MCP-Server bietet Zugang zu API-Dokumentation und Referenzmaterialien. Er ermöglicht KI-Assistenten, die ShipStation-API-Spezifikationen zu erkunden, Endpunkte zu erklären und Ihre Integrationsarbeit zu leiten. Für direkte API-Operationen verwenden Sie die ShipStation-API mit Ihren Anmeldedaten."

Ein mit diesem Server verbundener Agent kann Fragen wie „Wie lautet das Schema der Label-Ressource?" oder „Zeige mir alle verfügbaren ShipStation-Endpunkte" beantworten. Er kann keine Etiketten erstellen, Bestellungen auflisten oder den Verfolgungsstatus prüfen. Der Dokumentations-MCP ist ein Entwickler-Produktivitätstool, kein Betriebstool. Er hilft einem menschlichen Entwickler, eine Integration schneller zu erstellen. Er erlaubt einem Agenten nicht, die Versandplattform zu betreiben.

Dieselbe Muster wie bei BigCommerce, das einen dokumentationsbasierten MCP unter docs.bigcommerce.com/_mcp/server für die Entwicklerdokumentationssuche veröffentlicht hat. Beide Anbieter erkannten, dass MCP der Standard für KI-Werkzeugzugriff ist, und veröffentlichten eine Dokumentationsoberfläche. Keiner veröffentlichte einen transaktionalen MCP-Server für Store-Operationen. Der Unterschied ist, dass BigCommerce eine Partnerschaft mit Stripe für die Agentic Commerce Suite einging, um den Konsumenten-Agent-Pfad abzudecken. ShipStation ging keine Partnerschaft für eine vergleichbare transaktionale Agentenoberfläche ein.

Pfad 2: Verwaltetes MCP (StackOne, Zapier, Community)

Drei Drittanbieter-verwaltete MCP-Server umhüllen die ShipStation-API für Agentenzugriff:

StackOne veröffentlicht 45 vorgebaute Aktionen, die Carrier (auflisten, abrufen), Kunden (auflisten, abrufen), Bestellungen (auflisten, abrufen, löschen, erstellen oder aktualisieren, Tag-Verwaltung, sperren/wiederherstellen, Benutzer zuweisen, als versendet markieren), Produkte (auflisten, abrufen, aktualisieren), Stores (auflisten, abrufen, aktualisieren, aktualisieren, deaktivieren, reaktivieren), Lager (vollständiges CRUD), Etiketten (erstellen, stornieren), Tarife (Versandtarife abrufen), Fulfillments (auflisten) und Kontoverwaltung (registrieren, Benutzer auflisten, Tags auflisten, Carrier-Pakete und -Dienste) abdecken. StackOne bietet verwaltete pro-Benutzer-OAuth-Authentifizierung, Prompt-Injection-Verteidigung (88,7% Genauigkeit, nur CPU) und eine Werkzeugentdeckungsebene, die Kontextaufblähung reduziert. Die Aktionen mappen auf die ShipStation V1-API-Oberfläche.

Zapier MCP macht ShipStation-Aktionen über Zapiers MCP-Client verfügbar. Aktionen umfassen Bestellungen erstellen, Sendungen verwalten und Webhooks auslösen. Zapier verwaltet die Authentifizierung zentral — keine exponierten Anmeldedaten. Die Einschränkung ist der Aufgabenverbrauch: Jeder MCP-Aufruf zählt als Zapier-Aufgabe, und die ShipStation V1-API läuft bereits mit 40 Anfragen pro Minute. Ein Agent, der sequenzielle Aufrufe durchführt, kann Aufgabenkontingente schnell erschöpfen.

Community-MCP-Server (mattcoatsworth, MIT-Lizenz, 3 GitHub-Sterne, letzter Commit April 2025) umhüllt die V1-API mit Basic Auth (API Key + Secret). Er deckt Bestellungen, Sendungen, Carrier, Lager, Produkte, Kunden, Stores, Webhooks und Fulfillments ab. Die Werkzeugliste ist umfassend — list_orders, get_order, create_order, mark_order_as_shipped, create_label, void_label, list_carriers, list_warehouses, subscribe_to_webhook. Aber der Server wurde seit April 2025 nicht aktualisiert, läuft gegen die abschreibungsgefährdete V1-API und hat keine verwaltete Authentifizierung, keine Ratenlimit-Durchsetzung und keine Audit-Logs.

Die verwalteten MCP-Server lösen das Verbindungsproblem: Ein Agent kann ShipStation-Daten über eine typisierte Werkzeugschnittstelle lesen und schreiben. Sie lösen nicht das Semantikebenen-Problem. StackOnes 45 Aktionen sind generische Wrapper um die ShipStation-API. Keine kodiert Geschäftsbedeutung — welche Bestellungs-Benutzerdefinierten-Felder auf welche NetSuite-Benutzerdefinierten-Felder mappen, welche Versandkosten auf welches GL-Konto gebucht werden sollen, welcher Lagerstandortname Zeichen für Zeichen mit dem NetSuite-Location-Feld übereinstimmen muss. Die verwalteten Server erzwingen auch kein werkzeugspezifisches Ratenlimit. Ein Agent, der 30 parallele Aufrufe gegen das 40-Anfragen-pro-Minute-Fenster der V1-API durchführt, würde das Limit in Sekunden erschöpfen, und der verwaltete Server würde es nicht verhindern.

Pfad 3: Benutzerdefiniertes MCP-Modul (V2-API)

Der Produktionspfad für B2B-ShipStation-Integrationen ist ein benutzerdefiniertes MCP-Modul gegen die V2-API. Dies ist dieselbe Schlussfolgerung, zu der die Connector-Reihe für jeden Anbieter gelangt: Der Erstanbieter- oder verwaltete Server löst das Verbindungsproblem, und das benutzerdefinierte Modul löst das Semantikebenen-Problem. Für ShipStation sind die spezifischen Lücken, die ein benutzerdefiniertes Modul füllt:

1. Mapping benutzerdefinierter Felder zu NetSuite — der integrierte NetSuite-Connector unterstützt drei Feld-Mapping-Varianten und kann keine benutzerdefinierten Felder mappen wie Rabatte, Geschenknachrichten oder spezielle Bearbeitungsanweisungen. Ein benutzerdefiniertes MCP-Modul kann ShipStation-Bestellungs-Benutzerdefinierte-Felder lesen und in die übereinstimmenden NetSuite-Benutzerdefinierten-Felder auf dem Item Fulfillment-Datensatz schreiben und die Lücke schließen, die Nova Module für 400 $/Monat füllt.

2. V2-API-Ausrichtung — die V2-API läuft mit 200 Anfragen pro Minute (5x das V1-Limit) und enthält Fähigkeiten, die die V1-API vermissen lässt: Batch-Etiketten, Rücksendeetiketten, Multi-Paket-Etiketten, Manifeste, Abholungen und Bestandsverwaltung. Ein benutzerdefiniertes Modul, das auf V2 abzielt, vermeidet den V1-Abschreibungszeitplan und gewinnt die höhere Ratenobergrenze.

3. Werkzeugspezifische Ratenlimit-Durchsetzung — die 200 Anfragen/Min der V2-API werden über alle Anfragen geteilt. Ein benutzerdefiniertes Modul kann werkzeugspezifisches Throttling erzwingen und sicherstellen, dass ein Tarifvergleichs-Agent mit 20 Carrier-Abfragen nicht das Fenster eines Etikettenerstellungs-Agenten erschöpft. Der Retry-After-Header auf 429-Antworten liefert das Signal für Backoff-Logik.

4. Prüfbare Schreibpläne — verwaltete MCP-Server führen sofort aus. create_label, mark_order_as_shipped und void_label sind irreversible Operationen, die reale Kosten verursachen (keine Sandbox für Plattformnutzer). Ein benutzerdefiniertes Modul kann Entwurf-Prüfung-Genehmigung-Workflows für Schreiboperationen implementieren, mit Human-in-the-Loop-Kontrollpunkten vor der Etikettenerstellung oder Bestellungenlöschung.

5. ERP-Writeback mit semantischem Mapping — wenn ShipStation ein Etikett erstellt und eine Tracking-Nummer zurückgibt, bucht der integrierte NetSuite-Connector die Tracking-Nummer, den Carrier-Code und die Versandkosten zurück auf NetSuite. Aber der Connector kann die tatsächlichen Versandkosten nicht auf das richtige GL-Konto mappen, weil er nicht weiß, welches GL-Konto Fracht für diese Tochtergesellschaft darstellt. Ein benutzerdefiniertes Modul kodiert dieses Mapping als typisiertes Werkzeug und bucht den Fulfillment mit der korrekten GL-Kodierung.

Die V1/V2-API-Aufteilung

ShipStation betreibt zwei API-Versionen parallel, und die Aufteilung ist für die Agent-Integration wichtig, weil sie Ratenlimits, Authentifizierung und Langlebigkeit bestimmt.

V1-API (Legacy): Verwendet Basic Authentication (Base64-kodierter API Key:API Secret). Ratenlimit: 40 Anfragen pro Minute pro API-Key/Secret-Set. HTTP-429-Antwort mit X-Rate-Limit-Remaining-Header bei Überschreitung. Die V1-API ist seit über einem Jahrzehnt aktiv und wird zukünftig abgeschrieben. Der Community-MCP-Server (mattcoatsworth) und das StackOne-verwaltete MCP zielen beide auf V1. Der integrierte NetSuite-Connector verwendet V1-Ära-Integrationsmuster.

V2-API (aktuell, ehemals ShipEngine): Verwendet API-Key-Header-Authentifizierung. Ratenlimit: Standard 200 Anfragen pro Minute, über Support höher anfragbar. HTTP-429-Antwort mit Retry-After-Header (Sekunden Wartezeit). V2 fügt Batch-Etiketten, Rücksendeetiketten, Multi-Paket-Etiketten, Manifeste, Abholungen und Bestandsverwaltung hinzu — Fähigkeiten, die V1 fehlen. Ein V2-Schlüssel gleichzeitig aktiv. HTTPS und TLS 1.1+ erforderlich.

Sandbox-Lücke: ShipStation-Plattformnutzer (V1/V2-API) haben keine Sandbox-Umgebung. Alle API-Operationen erfolgen in der Produktion und können reale Kosten verursachen — einschließlich Etikettenerstellung, die echte Carrier-Gebühren generiert. Die ShipEngine-Sandbox (mit TEST_-präfixierten Schlüsseln) ist nur für ShipStation-API-Nutzer (ehemals ShipEngine) verfügbar, nicht für ShipStation-Plattformnutzer. Das bedeutet, dass ein Agent, der die Etikettenerstellung gegen die V2-API testet, echte Etiketten zu echten Kosten generiert. Ein benutzerdefiniertes Modul sollte sorgfältige Testpraktiken implementieren: kostengünstige Versandoptionen für Testetiketten, sofortige Stornierung über den void-label-Endpunkt und kleine Volumina während der Entwicklung.

Die Ratenlimit-Lücke zwischen V1 und V2 ist der operativ bedeutendste Unterschied für Agent-Workloads. Ein Agent, der Tarifvergleich über 5 Carrier für 10 Sendungen durchführt, macht 50 API-Aufrufe in einem Burst. Gegen das 40-Anfragen/Min-Limit von V1 überschreitet dieser Burst das Fenster vor Abschluss. Gegen die 200 Anfragen/Min von V2 passt er mit Spielraum. Für Batch-Operationen — die V2-API unterstützt Batch-Etikettenerstellung, die Hunderte von Etiketten in einer einzigen Anfrage verarbeitet — ist die V2-Ratenobergrenze essentiell.

Die Lücke bei benutzerdefinierten Feldern des NetSuite-Connectors

ShipStations integrierte NetSuite-Integration ist die häufigste ERP-Verbindung für ShipStation-Händler. Sie kostet 200 $/Monat nach einer 30-Tage-Testphase und verwendet Token-Based Authentication (TBA) — dasselbe OAuth 1.0a mit HMAC-SHA256-Muster, das der NetSuite MCP-Modul-Artikel als Produktionsauthentifizierungs-Standard für Headless-NetSuite-Operationen identifiziert.

Der Connector bietet drei Workflow-Optionen:

• Sales Order — ShipStation verarbeitet Kommissionierung, Verpackung und Versand. NetSuite „Pending Fulfillment"-Bestellungen exportieren automatisch.
• Pick Flow — NetSuite verwaltet die Kommissionierung. Nur „Picked" Item Fulfillment Records exportieren zu ShipStation.
• Pack Flow — NetSuite verwaltet Kommissionierung und Verpackung. Nur „Packed" IFRs exportieren zur Etikettenerstellung.

Der Connector fragt NetSuite alle 3-10 Minuten ab und bucht Fulfillment-Daten (Tracking-Nummer, Carrier, Versandkosten, Versanddatum) innerhalb von 5-10 Minuten nach der Etikettenerstellung zurück. Die bidirektionale Synchronisierung eliminiert manuelle Dateneingabe — Anchor Group berichtet von Unternehmen, die 4-5 Stunden täglicher manueller Tracking-Updates eliminierten.

Die Lücke ist das Mapping benutzerdefinierter Felder. Der Connector unterstützt nur drei Feld-Mapping-Varianten und gibt explizit an: „Wenn Sie weitere Anpassung benötigen, empfehlen wir die Verwendung unseres Custom Store Development Guide." Benutzerdefinierte Felder — Rabatte, Geschenknachrichten, spezielle Bearbeitungsanweisungen, kundenspezifische Versandpräferenzen — synchronisieren nicht. Standortnamen müssen Zeichen für Zeichen zwischen Systemen übereinstimmen, sonst werden keine Etiketten generiert. SKUs müssen exakt übereinstimmen, sonst werden Artikel als nicht erkannt importiert.

Drittanbieter-Connectors füllen die Lücke gegen Bezahlung. Nova Module berechnet 400 $/Monat (jährlich abgerechnet) für das Mapping benutzerdefinierter Felder. Celigo bietet iPaaS-Level-Integration mit kundenspezifischer Preisgestaltung. Für einen Händler, der 200 Bestellungen pro Tag mit 15 benutzerdefinierten Feldern pro Bestellung verarbeitet, verbraucht der manuelle Workaround (Kopieren-Einfügen von benutzerdefinierten Feldwerten von ShipStation nach NetSuite) dieselben Stunden, die der Connector eliminieren sollte.

Ein benutzerdefiniertes MCP-Modul schließt diese Lücke, indem es ShipStation-Bestellungs-Benutzerdefinierte-Felder über die V2-API liest und sie über den NetSuite AI Connector oder die direkte SuiteTalk REST-API in übereinstimmende NetSuite-Benutzerdefinierte-Felder schreibt. Das Modul kodiert das Feld-Mapping als typisiertes Werkzeug: map_shipstation_custom_fields_to_netsuite(order_id, fulfillment_id) — mit der Mapping-Tabelle als Konfiguration, nicht als hartkodierte Logik. Dies ist dasselbe Muster, das der NetSuite-MCP-Modul-Artikel für die Semantikebenen-Lücke beschreibt (welche GL-Konten „Umsatz" sind), angewendet auf das Versandplattform-zu-ERP-Feld-Mapping-Problem.

Die Legacy-NetSuite-Integration wird am 30. Juni 2026 abgeschaltet und durch eine NetSuite Beta-Integration ersetzt. Die Abschaltung erhöht die Dringlichkeit: Händler auf dem Legacy-Connector müssen migrieren, und die Migration ist eine Gelegenheit zu prüfen, ob ein benutzerdefiniertes MCP-Modul eine bessere Abdeckung benutzerdefinierter Felder bietet als der Ersatz-Connector.

Was ein benutzerdefiniertes ShipStation MCP-Modul kodiert

Gemäß dem MCP Module Code Standard kodiert ein benutzerdefiniertes ShipStation MCP-Modul fünf Dinge, die der Dokumentations-Server und die verwalteten Wrapper nicht haben:

1. Typisierte Schemata für V2-Endpunkte — jeder V2-API-Endpunkt erhält eine JSON-Schema-Eingabedefinition mit Pflichtfeldern, optionalen Feldern und Validierungsbedingungen. Das create_label-Werkzeug spezifiziert shipment_id, carrier_id, package_type und weight als Pflicht; label_format, test_label und return_label als optional. Der Agent kann das Werkzeug nicht mit fehlenden Pflichtfeldern aufrufen.

2. Ratenlimit-bewusste Ausführung — das Modul erzwingt ein werkzeugspezifisches Nebenläufigkeitslimit und eine globale Ratenobergrenze unterhalb der 200 Anfragen/Min der V2-API. Jeder Werkzeugaufruf zeichnet seinen Zeitstempel auf; das Modul lehnt Aufrufe ab oder reiht sie ein, die das Budget überschreiten würden. Der Retry-After-Header von 429-Antworten speist die Backoff-Logik mit exponentieller Verzögerung.

3. Mapping-Tabelle für benutzerdefinierte Felder — das Modul lädt eine Konfiguration, die ShipStation-Feldnamen NetSuite-internen Feld-IDs zuordnet. Wenn ein Agent sync_fulfillment_to_netsuite(order_id) aufruft, liest das Modul die ShipStation-Bestellungs-Benutzerdefinierten-Felder, übersetzt sie über die Mapping-Tabelle und schreibt das NetSuite Item Fulfillment mit den korrekten benutzerdefinierten Feldwerten.

4. Prüfbare Schreibpläne — für irreversible Operationen (Etikettenerstellung, Bestellungenlöschung, Etikettenstornierung) gibt das Modul einen Entwurfsplan vor der Ausführung zurück. Der Agent präsentiert den Plan dem menschlichen Operator zur Genehmigung. Nach Genehmigung führt das Modul die Operation aus und zeichnet die Audit-Spur auf — wer genehmigte, wann, was sich änderte, was die Kosten waren.

5. GL-Kodierung für Versandkosten — beim Zurückbuchen der Fulfillment-Daten auf NetSuite wendet das Modul die GL-Kodierungskonfiguration an: Welches Konto stellt Frachtkosten für diese Tochtergesellschaft dar, welche Abteilung gilt für diesen Standort, welcher Klassencode mappt auf diese Versandmethode. Der integrierte Connector bucht die rohen Versandkosten; das benutzerdefinierte Modul bucht die Kosten mit der korrekten GL-Kodierung, sodass die Margenanalyse des Finanzteams ohne manuelle Umbuchung genau ist.

Verwandte Lektüre

• Einen KI-Agenten mit Brightpearl verbinden: Wenn es keinen Erstanbieter-MCP-Server gibt — der fünfte Connector der Reihe, bei dem das benutzerdefinierte Modul die Integration selbst ist, kein Lückenfüller. ShipStation und Brightpearl teilen sich das Shopify-Ökosystem — Brightpearl ist das ERP, ShipStation ist die Versandschicht.
• MCP Module Code Standard — das Strukturmuster, das benutzerdefinierte Module produktionsreif über alle Connectors macht, einschließlich Ratenlimit-Durchsetzung und prüfbaren Schreibplänen.
• Einen KI-Agenten mit NetSuite verbinden mit MCP: das Modulmuster — der ERP-Seiten-Connector. ShipStations Lücke bei benutzerdefinierten Feldern ist ein NetSuite-Mapping-Problem; dieser Artikel behandelt die TBA-Authentifizierung und das Muster zur Auflösung benutzerdefinierter Felder.

Einen definierten Build anfordern

Ein Distributor, der NetSuite, BigCommerce und ShipStation nutzt, verarbeitet 200 Bestellungen pro Tag. Jede Bestellung trägt 12 benutzerdefinierte Felder — Geschenknachrichten, spezielle Bearbeitung, kundenspezifische Versandanweisungen. Der integrierte ShipStation-NetSuite-Connector synchronisiert Tracking-Nummern und Versandkosten automatisch, aber die 12 benutzerdefinierten Felder mappen nicht. Jemand kopiert sie von Hand, jede Bestellung, jeden Tag. Ein benutzerdefiniertes MCP-Modul liest die ShipStation-Benutzerdefinierten-Felder, übersetzt sie über eine Mapping-Tabelle und schreibt sie in die übereinstimmenden benutzerdefinierten Felder von NetSuite auf dem Item Fulfillment-Datensatz — mit GL-Kodierung für die Versandkosten, prüfbaren Schreibplänen für die Etikettenerstellung und werkzeugspezifischer Ratenlimit-Durchsetzung gegen die 200-Anfragen/Min-Obergrenze der V2-API.

Eine Woche Discovery. Sie erhalten ein Systeminventar, eine Workflow-Mappe und einen festen Umfang — ob Sie mit uns bauen oder nicht.