BoostEcom betreibt einen entfernten MCP-Server, einen Endpunkt pro verbundenem Store. Es ist die Oberfläche, über die ein KI-Client einen Shopify-Store und die daran hängenden BoostEcom-Daten liest.

Nur Lesen. Jedes Tool im Katalog ist ein Lesezugriff, auch das, das ein GraphQL-Dokument annimmt: shopifyAdminGraphQL führt Queries aus und lehnt Mutations namentlich im Handler ab. Ein Schreibzugriff auf einen Live-Store ist eine Entscheidung, die jemand freigeben muss, und in einem Relay sitzt niemand: Ein KI-Client ruft auf, der Aufruf kommt an, nichts steht dazwischen. Solange es keinen Freigabeweg gibt, ist Ablehnen die einzige Antwort, die den Katalog eines Kunden nicht stillschweigend verändern kann.

Der Endpunkt

https://boostecom.app/api/mcp/v1/<storeId>

Die unversionierte Form, /api/mcp/<storeId>, wurde zuerst ausgeliefert und wird seither in der Konfiguration jedes installierten Clients gehalten. Sie bleibt, genau so, wie sie ist. Die beiden sind ein Endpunkt mit zwei Namen: dieselben Handler, und ein über einen der beiden geprägtes Token funktioniert auf beiden.

Verwenden Sie den v1-Pfad für alles Neue.

Zwei Auth-Modi

| Modus | Anmeldeinformation | Geöffnete Tool-Familien | |---|---|---| | OAuth 2.1 PKCE | Zugriffstoken von /oauth/authorize | Relay und native. | | Statisch | bst_mcp_-Bearer | Nur Relay: die 15 Relay-Tools, innerhalb der Shopify-Berechtigungen des Stores. |

Die Asymmetrie ist beabsichtigt und wird in MCP-Tools & Scopes erklärt.

Ein statischer Schlüssel trägt keinen Scope-String: Er wird als ererbte Gewährung gelesen, und die erweitert sich zur Relay-Familie und zu nichts sonst. Das hat zwei Folgen. Die public-Dokumentations-Tools searchDocs und getDoc würden einen Aufrufer zulassen, den das Relay nicht benennen kann, aber ein statischer Schlüssel nennt ihren Scope nie: Sie werden für ihn nicht registriert und erreichen einen Client nur über OAuth. Und die native-Tools werden für einen statischen Schlüssel nie registriert, unabhängig von der Gewährung, weil sie einen identifizierten Aufrufer verlangen.

Was ein Tool absichert

Drei Tore, und ein Tool muss alle davon passieren, um für eine bestimmte Sitzung registriert zu werden:

Der genehmigte BoostEcom-Scope: wozu der Benutzer eingewilligt hat.
Die Shopify-Scopes des Stores: eine harte Obergrenze. Hat die Custom App oder die OAuth-Installation nie read_orders erhalten, beschwört kein BoostEcom-Scope es herbei.
Ein identifizierter Aufrufer: nur von native-Tools benötigt, weil deren Berechtigung von einer Organisationsmitgliedschaft abhängt und es im statischen Modus niemanden zum Prüfen gibt.

Ein Tool, das an einem Tor scheitert, wird nicht registriert: es erscheint überhaupt nicht in der Tool-Liste des Clients, statt zu erscheinen und beim Aufruf zu scheitern. Das ist das richtige Verhalten für einen KI-Client: ein Tool, das er sehen kann, ist ein Tool, das er versuchen wird.

Einen Client verbinden

Vier Clients haben eine Schritt-für-Schritt-Anleitung:

Jede gibt die URL, den von diesem Client unterstützten Auth-Modus und einen einfügebereiten Konfigurationsausschnitt an.

Agenten-Erkennung

Die Plattform veröffentlicht ein UCP-Agentenprofil unter /.well-known/ucp-agent. Es erklärt eine Katalog-Lesefähigkeit und trägt keine Geheimnisse. Es ist das, was jeder von uns abgefragte Shopify-Store liest, um unsere Fähigkeiten auszuhandeln, bevor er antwortet.

Weiter

MCP-Tools & Scopes: der vollständige Katalog.
Authentifizierung: eine Anmeldeinformation wählen.