44up Observatory · MCP / Agentic-Commerce Briefing

Von lesbar zu
transaktierbar.

Das Fabular-Schaufenster hat seit Runde 1–2 einen funktionierenden MCP-Server bekommen: ein Agent kann suchen und einen Warenkorb füllen. Eine Nachmessung am selben Tag — drei von vier Befunden waren binnen Stunden behoben. Ein Blocker bleibt.

fabular.pages.dev/api/mcp Erstprobe + Recheck 2026-06-06 9 Tools · 0 fabrizierte Werte
44°N
9
MCP-Tools
JSON-RPC 2.0 · live
3/4
Punch-list behoben
am selben Tag
1
Blocker offen
Sessions nicht durabel
≥381
Produkte im Katalog
llms.txt nennt „150+"

Es funktioniert — Credit first

9 Tools · live

Echtes JSON-RPC 2.0 über /api/mcp: initializetools/list (9 Tools mit sauberem inputSchema) → tools/call liefert live, strukturierte Daten — Suche, Warenkorb, Angebote, Lebensmittelrettung, Empfehlungen. Anbindbar aus Claude Desktop und ChatGPT per npx mcp-remote laut der eigenen /mcp-Seite.→ Die Decke ist gestiegen: von „KI-lesbar" (Runde 1–2) zu Agent-transaktierbar. Niemand sonst im getrackten DACH-Bio-Liefermarkt hat das.

Recheck-Delta — 3 von 4 am selben Tag behoben

✓ ✓ ◐
✓ MHD

Lebensmittelrettung-Daten: jedes Produkt war auf 1970-01-0X datiert (Epoch-Artefakt) — im emotional aufgeladensten Feature. Jetzt: echte Daten in naher Zukunft (2026-06-08, 2026-06-07; heute ist der 06.06.).→ Der quotierbarste Bug ist weg.

✓ isError

Tool-Fehler lieferten zuvor immer isError:false + HTTP 200, den Fehler als Prosa — ein Agent konnte Misserfolg nicht erkennen. Jetzt: isError:true bei unbekanntem Tool und fehlendem Pflichtargument (konform zu MCP SEP-1303).→ Agenten können sich selbst korrigieren.

◐ llms.txt

Die Produktzahl in llms.txt ging von „über 40" auf „150+" — verbessert, aber noch nicht geschlossen: ein breiter Suchlauf vereint ≥381 eindeutige SIDs, also ~2,5× Untererfassung (vorher ~10×).→ „150+" auf den realen Katalog (≥381) heben.

Der eine Blocker — Sessions nicht durabel

🔴 §2.1
+ CORS

Berührt, nicht geschlossen: mcp-session-id (der Spec-Header-name) steht jetzt im erlaubten CORS-Set. Aber der Spec-Ablauf wird nicht bootstrappt — und Warenkorb-Roundtrips sind unabhängig davon unzuverlässig.

1 · initialize gibt kein Mcp-Session-Id aus → ein Standard-mcp-remote-Client bekommt keine Session zum Mitsenden. 2 · cart_add meldet immer "success": true, cart_total_items: 1 — ein verlorener Korb ist kein fehlgeschlagenes Add. 3 · gleiche Session, cart_add → sofort cart_get (n=15): Korb in 11 von 15 Versuchen leer (item_count:0). ohne Header teilen sich alle Clients einen Default-Korb (die ursprüngliche Kollision).
→ Fix

Beobachtet ist die Verlustrate; die Ursache (kein durabler Session-Store hinter dem Serverless-Endpoint) ist abgeleitet — von einer Egress-IP nicht hart festnagelbar, und das muss sie auch nicht sein: jede Variante ist falsch für echte Bestellungen.→ Spec-Mcp-Session-Id-Ablauf (Server-vergeben bei initialize, Client-Echo) plus durabler Per-Session-Speicher. Harmlos im flüchtigen Demo ohne Checkout — Blocker, sobald ein Live-Tenant echte Bestellungen hält.

Offene Datenqualität — über den Agenten sichtbar

2 offen
UoM

unitOfMeasure: gewichts-/volumenbenannte Artikel weiter als Stück getaggt — Bio-Karotten 2 kg, Karotten bunt 500g, Karottensaft 1l. Die klassische Agent-Aufgabe „günstigste Karotten pro kg" rechnet falsch.→ Gewichtseinheiten auf gewichtsverkaufte Artikel setzen.

Dup

Verdacht-Dublette: art-61033 „Karottenkuchen Stück" @ 2,99 € und art-40051 „Karottenkuchen-Stück" @ 3,29 € — wahrscheinlich derselbe Artikel, zwei SIDs, zwei Preise.→ Dedup prüfen; ein Agent würde beide zeigen und ggf. den falschen Preis nennen.

Ein Session-Store. Die drei Einzeiler waren schon erledigt.

Das Demo wurde binnen Stunden messbar besser — drei von vier forwardbaren Punkten geschlossen, einer (llms.txt) halb. Die eine Lücke, die für einen produktiven Tenant tragend ist — durable, spec-gebootstrappte Sessions — ist die, die offen bleibt.

Strategischer Kontext: Der MCP-Server ist eine Plattform-Fähigkeits-Demo — „Fabular-Shops können agent-einkaufbar sein" — kein Beleg, dass ein Live-/ACM/-Tenant einen exponiert. Der JS-vermauerte Roster (StorePulse-Audit 2026-06-05: Tenant-Shops KI Ø 3,6/100, 100 % vermauert) ist nicht crawlbar, geschweige denn transaktierbar. Das Demo zeigt das Ziel; die Tenants stehen noch auf dem Parkplatz.