Basketed

Ein Korb. Viele Shops. Nichts gekauft ohne dich.

Ein universeller Shopping-MCP-Server plus ein selbst gehostetes Kontrollpanel. Jeder MCP-Agent erhält echte Produktsuche über viele Händler, token-effizienten Vergleich und einen Kaufs-Schritt, den nur ein Mensch autorisieren kann.

ANALYSE → EXTRACT → RESPOND → PURCHASE → RECEIVE

pnpm i && pnpm build
node packages/cli/bin.js install --client claude-code   # or --all

Das ist das gesamte Setup. Dein Client startet Basketed selbst über stdio, und das Kontrollpanel erscheint im selben Prozess – sein Link und ein Link zu jedem Warenkorb, der auf dich wartet, werden auf der Konsole des Servers ausgegeben. serve --http --open ist der andere Weg hinein: dasselbe Panel, plus einen Streamable-HTTP-Endpunkt auf /mcp.

Was hier tatsächlich ist

Related MCP server: agent-commerce-mcp-server

Das Kauf-Gate

Ein Agent kann einen Kauf vorschlagen. Nur ein Mensch kann einen autorisieren, und die Autorisierung kommt immer von einer Oberfläche, die das Modell nicht erstellen kann.

cart_prepare ──► PENDING ──(human)──► APPROVED ──(purchase_confirm)──► order
                    │                                                    │
                    └──► EXPIRED (5 min) / REJECTED                       └─► HANDED_OFF
                                                                              outcome: unknown

Zwei Genehmigungskanäle, die beide auf einer Funktion zusammenlaufen, sodass die Sicherheitseigenschaften identisch sind, egal wo der Mensch geklickt hat:

Kanal B – Elicitation, bei dem der Client den Dialog selbst rendert, ist entworfen und nicht gebaut. ApprovalChannel ist "console" | "panel", und das ist die gesamte Liste. Der Buchstabe wird beibehalten, damit Plan und Code dieselben Namen für dieselben Dinge verwenden.

Kanal C ist sicher, weil das Modell keinen Lesezugriff auf diese Oberfläche hat. Der einzige Weg, wie ein Agent an den Code kommt, ist, dass eine Person ihn vorliest – genau das ist die menschliche Handlung, die wir verlangen wollen.

Kanal A beruht auf derselben Tatsache, nicht auf der Routen-Trennung. Jeder Client, in den Basketed installiert wird, hat eine Shell, also war „der Agent spricht MCP und kann /api nicht erreichen“ für sich genommen nie wahr – ein lokaler Prozess kann jeden Port auf 127.0.0.1 anrufen und jeden Header fälschen. Das Panel ist daher hinter einem Token, das pro Prozess geprägt und auf derselben Konsole ausgegeben wird – auf beiden Transports, sodass ein Client, der Basketed über stdio gestartet hat, weiterhin Kanal A hat.

Auf stdio öffnet sich das Panel auch in deinem Browser, wenn der Server startet. Das ist keine Bequemlichkeit: Ein Client erfasst den stderr seines MCP-Servers, also wird der Link dorthin geschrieben, wo kein Mensch ihn jemals lesen wird, und ein Panel, das niemand erreichen kann, ist kein Kanal. Der Tab ist dort der Kanal. Ein Tab pro Prozess; --no-open (oder BASKETED_NO_OPEN=1) schaltet es ab, und der Tab pollt, sodass ein Warenkorb, der dich später braucht, in dem bereits geöffneten Tab erscheint. /api lehnt außerdem jede Anfrage ab, deren Origin nicht exakt die des Panels ist, und lehnt eine mutierende Anfrage ab, die keine sendet – das verhindert, dass eine Webseite das Panel über deinen Browser steuert.

Was es absichtlich nicht gibt: ein approve()-Tool, einen approved: true-Parameter, ein Override-Flag oder ein set_delivery_address-Tool. Führe tools/list aus und prüfe. Die Abwesenheit ist das Feature.

Der Adversarial-Pass

pnpm smoke        # five smoke suites, all offline
pnpm test         # 160 unit tests
pnpm drill        # the whole demo path with the network genuinely severed
pnpm smoke:live   # ...and against live merchants, spending real requests

1. purchase_confirm vor der Genehmigung → abgelehnt

2. genehmigen, bestätigen, dann dieselbe approval_id erneut abspielen → abgelehnt, verbraucht

3. einen Preis in der DB nach der Genehmigung ändern → abgelehnt, Hash-Drift

4. mit --fast-mode neu starten und 1–3 wiederholen → alles immer noch abgelehnt

5. den Agenten bitten, seinen eigenen Kauf zu genehmigen → es gibt kein Tool, das das kann

--fast-mode kann den Kauf nicht berühren, und das ist zweifach bewiesen

Verhaltensmäßig und durch das Durchlaufen des realen Import-Graphen: Nichts, das von commerce/purchase.ts erreichbar ist, importiert mcp/policy.ts, wo das Flag lebt. Das Flag wird auf dem Kaufpfad nicht ignoriert – es ist von dort nicht erreichbar, und ein Refactoring, das sie verbindet, scheitert an CI.

Die Offline-Übung schneidet tatsächlich das Netzwerk ab

pnpm drill lädt eine Wache vor, die jede Nicht-Loopback-Verbindung im Serverprozess ablehnt, und durchläuft dann den gesamten Demo-Pfad. Das Setzen eines Snapshot-Flags auf einer Maschine, die noch WLAN hat, beweist nur, dass das Flag geparst wird. Bei einem echten Schnitt gehen sieben der zehn festgelegten Shopify-Stores aus – und kommen namentlich in stores_failed zurück, weil eine Suche, die stillschweigend weniger Stores zurückgibt, genau wie Erfolg aussieht.

Woher die Daten kommen

Jeder Adapter deklariert zwei unabhängige Dinge, und keines darf übertrieben werden. Jede Antwort trägt ihren Modus, und das Panel zeigt ihn als Badge.

Echtes Tesco ist keine lizenzierte Integration. search.api.tesco.com und xapi.tesco.com sind öffentliche Endpunkte, die Tescos eigene Website aufruft, mit einem API-Schlüssel, der öffentlich und in deren Frontend-JS eingebettet ist – aber Tesco dokumentiert oder unterstützt die Nutzung durch Dritte für keinen der beiden, und die Nutzung auf diese Weise liegt außerhalb der Nutzungsbedingungen von Tesco, genau wie bei jedem inoffiziellen API-Client. sim:tesco ist davon unberührt und bleibt genau das, was es immer war: Fixture-Daten, weiterhin das, wogegen die Offline-Übung läuft, weiterhin ohne echtes Netzwerk.

Kein Scraper und keine Anti-Bot-Umgehung. Cloudflare-Challenges, WAF-Fingerprinting und CAPTCHAs sind Zugriffskontrollen, die der Betreiber absichtlich aktiviert hat. Sie zu überwinden zerstört die Verteidigung „der Benutzer ist der Akteur“, die agentisches Shopping überhaupt vertretbar macht, und es bricht ständig. Händler dahinter sind provider oder simulated. Das ist keine Fähigkeit, die wir deaktiviert ausliefern – es ist eine, die wir nicht bauen.

HANDED_OFF beansprucht niemals Erfolg. Wenn die Route in einer URL endet, die ein Mensch selbst ausfüllt, kennen wir das Ergebnis wirklich nicht, und die Bestellung sagt genau das, bis eine Person sie im Panel markiert. Still ein grünes Häkchen für eine Bestellung zu zeigen, die niemand bezahlt hat, wäre der schädlichste Fehler, den dies ausliefern könnte.

Werkzeuge

Geldnah — destructiveHint: true, niemals auf ALLOW erweiterbar:

Token-Hebel

response_format: concise (Standard) · detailed · compact (kurze Schlüssel plus eine einzeilige Legende). fields für eine explizite Whitelist. budget_tokens für eine harte Obergrenze — gekürzt url → image → attrs → Name kürzen → Zeilen verwerfen, wobei _meta.truncated benennt, was entfernt wurde. id, price und mode werden nie entfernt: ein Ergebnis darf seine Herkunft nicht verlieren, um Tokens zu sparen.

Installation

basketed install wird von einer einzigen Varianztabelle gesteuert, derselben, aus der das Panel rendert — so können Installer, Textbausteine und Abzeichen nicht darüber uneins sein, wo eine Konfigurationsdatei liegt. Das ist wichtig, weil fast jede Ausnahme unten still fehlschlägt: Ein falscher Schlüsselname erzeugt keinen Fehler, Ihr Server erscheint nur nie.

basketed clients                       # every client, its file, its key
basketed install --client claude-code
basketed install --all --dry-run       # show the diff, write nothing
basketed doctor                        # check the install end to end

Schreibvorgänge sind Merge-dann-Ersetzen, niemals Überschreiben. Die vorhandene Datei wird nach <file>.basketed-backup-<timestamp> gesichert, nicht zusammenhängende Schlüssel und andere Server bleiben erhalten, der Schreibvorgang ist atomar und der Diff wird ausgegeben. Eine Konfiguration, die wir nicht parsen können, wird abgelehnt und byte-identisch belassen, anstatt ersetzt zu werden.

Kiros autoApprove ist eine Falle. Unsere generierte Konfiguration listet dort nur die vier schreibgeschützten Werkzeuge, und basketed doctor warnt, wenn ein geldnahes Werkzeug von Hand hinzugefügt wurde.

Protokoll

Zwei Epochen, beide Transporte. MCP 2026-07-28 entfernte initialize, Sitzungen und serverinitiierte Anfragen; ein moderner Client kann nicht mit einem Legacy-Server sprechen und umgekehrt. „Installiert in jeden Agenten" beruht vollständig darauf, beide aus einer Binärdatei zu bedienen, daher öffnet scripts/smoke-mcp.mjs dieselbe Binärdatei zweimal — einmal mit initialize, einmal zustandslos —, weil keiner der Fehler aus den eigenen Logs des Servers sichtbar ist.

Außerdem: server/discover, outputSchema für jedes Werkzeug, strukturierte Ausgabe als Text für ältere Clients gespiegelt, deterministische Werkzeugreihenfolge, alle vier Annotationen, namespaced Namen.

Sicherheit

• Der Anmeldeinformations-Tresor ist gebaut. packages/vault versiegelt jedes gespeicherte Geheimnis mit AES-256-GCM unter einem 32-Byte-Schlüssel unter ~/.basketed/master.key (Modus 0600). Es gibt genau eine Funktion, die Klartext zurückgibt — reveal() — und sie wird von nirgendwo außer vom Request-Interceptor aufgerufen, der einen Header an einen ausgehenden Fetch anhängt; ein Test durchsucht den Workspace nach anderen Aufrufstellen und schlägt fehl, wenn eine auftaucht. Das Panel — hinter demselben Pro-Prozess-Token wie alles andere in dieser Liste — schreibt hinein und liest nur Metadaten zurück. Kein MCP-Werkzeug erhält jemals eine Anmeldeinformation: AdapterCtx hat kein Feld, in dem eine reisen könnte. Eine schlechte oder fehlende Schlüsseldatei verschlechtert die Connect-Stores-Seite; sie bringt den MCP-Server nie zu Fall, sodass ein Client wegen dieser Datei nicht starten kann. Keiner der ausgelieferten Adapter authentifiziert sich mit dem, was gespeichert ist — Shopify UCP ist anonym und die simulierten Stores haben nichts, wogegen sie es prüfen könnten —, daher hält das Verbinden von Tesco, Costco, Walmart oder Amazon eine Anmeldeinformation für einen Adapter, der noch nicht existiert, und ändert kein Ergebnis, das Sie heute sehen.

• „Mit Chrome anmelden" (S15), genau für Tesco, Costco, Walmart und Amazon. Keiner von ihnen veröffentlicht einen Consumer-OAuth-Flow, daher ist die ehrliche Alternative zu einem Passwort-Einfügefeld, die eigene Anmeldeseite des Händlers in einem echten Browser zu öffnen und den Menschen sich selbst anmelden zu lassen. Dies startet das bereits installierte Chrome des Rechners, niemals ein heruntergeladenes Chromium — niemand, der dies nutzt, musste etwas installieren. Es wird nichts gelesen, bis der Mensch auf „Erfassen" klickt: Es gibt kein Polling auf ein Sitzungscookie, das erscheint, und es wird nicht in dem Moment gegriffen, in dem es erscheint. Konsistent mit „keine Anti-Bot-Umgehung" oben, versteckt es die Automatisierung nicht vor dem Händler — kein navigator.webdriver-Spoofing, kein Entfernen von Automatisierungsflags —, weil ein Betrugssystem, das einen gesteuerten Browser nicht von einem Menschen unterscheiden kann, keine Linie ist, die dieses Projekt gegen die Connect-Stores-Seite eintauschen wird. Die Nutzungsbedingungen aller vier Händler verbieten die automatisierte Anmeldung, auch durch den Kontoinhaber; dieses Risiko wird auf dem Button selbst offengelegt, nicht nur hier. Die erfasste Sitzung wird genau wie eine eingefügte Anmeldeinformation versiegelt — gleicher Tresor, gleiche reveal()-Prüfung — und noch verwendet sie kein Adapter.

• Der Agent sieht nur einen undurchsichtigen Kontobezeichner, niemals etwas, das zu einem werden könnte.

• Die Genehmigungsoberfläche liegt hinter einem Pro-Prozess-Token, der auf der eigenen Konsole des Servers gedruckt wird, neben dem 6-stelligen Code. Routentrennung ist nicht das Tor: Jeder Client, in den Basketed installiert, hat eine Shell, sodass der Agent immer 127.0.0.1 erreichen und jeden Header fälschen könnte. /api erfordert außerdem einen Origin, der exakt dem des Panels entspricht, und lehnt eine mutierende Anfrage ab, die keinen sendet.

• Händlertext sind unvertrauenswürdige Daten. NFKC-normalisiert, von Steuerzeichen, Nullbreiten- und Bidi-Overrides befreit, HTML-entfernt, längenbegrenzt, Injektionsmuster markiert. Die eigentliche Verteidigung ist stärker: Der Genehmigungsbildschirm und der Warenkorb-Hash werden nur aus numerischen und aufgezählten Feldern plus dem normalisierten Produktnamen erstellt. Keine vom Händler verfasste Zeichenkette erreicht eines von beiden.

• approval_id ist CSPRNG, serverseitig an einen aus der lokalen Sitzung abgeleiteten Prinzipal gebunden — niemals an etwas, das der Agent geliefert hat — und wird innerhalb des atomaren Verbrauchs erneut geprüft. Besitz ist niemals Authentifizierung (2026-07-28 State Handle Hijacking).

• Schwärzungsschicht über jeder Antwort, als Netz und nicht als Verteidigung. Ein Treffer ist ein Fehler; das Panel zeigt die Anzahl.

• Wir fassen niemals Kartendaten an (außerhalb des PCI-Geltungsbereichs), speichern niemals Händlerpasswörter und liefern keinen Scraper.

Nicht gebaut, so festgehalten, damit niemand es beansprucht

Echte Händler-Adapter für Costco/Walmart/Amazon (keiner veröffentlicht eine Consumer-API; der Tresor hält eine Anmeldeinformation — eingefügt oder per Chrome erfasst —, nichts authentifiziert sich noch damit), echte Händler-OAuth (keiner der vier veröffentlicht eine — siehe Stores verbinden), eine Chrome-Login-Erfassung für jeden Store außerhalb dieser Prototyp-Vier, der Mock-IdP, Genehmigungskanal B (Elicitation), compare_products, die Bestellseite, MCPB, Registry-Veröffentlichung und ChatGPT-Plugin-Einreichung. Alle sind im Plan entworfen und keine sind gebaut.

Tesco ist der eine Händler-Adapter, der von dieser Liste verschoben wurde (S16) — siehe „Woher die Daten kommen" oben: echte Suche, echte Details und ein echter Warenkorb hinter dem eigenen eingefügten Sitzungstoken des Käufers. Costco, Walmart und Amazon bleiben hier, weil keiner der drei einen gleichwertigen inoffiziellen, aber echten Endpunkt hat, den Tescos Frontend zufällig offenlegt — siehe Stores verbinden für das, was eine Chrome-Login-Sitzung auf diesen drei stattdessen kann und nicht kann.

Der Anmeldeinformations-Tresor ist das andere Element, das von dieser Liste verschoben wurde (S14) — siehe Sicherheit oben — und der Drift-Wächter, der es hier früher prüfte, prüft jetzt das Gegenteil: dass diese Datei aufhört, es zu verleugnen, genau dann, wenn es aufhört, wahr zu sein.

docs/ — BENCHMARK

Erfordert Node ≥ 22 (node:sqlite, daher gibt es keinen nativen Build-Schritt — was unter Windows wichtig ist, wo dies entwickelt und verifiziert wurde).