Shopify und Vercel bauen Hydrogen als offene, runtime-agnostische Basis neu. Hydrogen deployt jetzt …
WebMCP vs. MCP im Commerce: Wo verlaeuft die Agenten-Grenze
Zwei Protokolle konkurrieren gerade um dieselbe Aufgabe: einen KI-Agenten auf einem Storefront handeln zu lassen. WebMCP fuehrt die Aktion im Browser aus, direkt auf dem, was der Nutzer ohnehin geoeffnet hat. MCP fuehrt sie gegen einen Server-Endpoint aus, den der Agent direkt aufruft. Beide loesen „wie handelt ein Agent", beantworten aber zuerst eine andere Frage: wo passiert das, Client oder Server? Fuer Teams, die 2026 agent-faehige Storefronts bauen, ist diese Platzierungsentscheidung inzwischen eine Architekturfrage, kein Implementierungsdetail.
Zwei Ebenen, eine Aufgabe: Actuation
WebMCP stellt Tools direkt im Browser-Kontext bereit. Ein Agent, der innerhalb einer Session, einer Browser-Extension oder eines agentischen Browsers arbeitet, kann Funktionen aufrufen, die die Seite selbst registriert: in den Warenkorb legen, einen Filter setzen, den Checkout starten, unter Nutzung von DOM und Client-State, die bereits existieren. Das Actuation-Prinzip selbst haben wir in wie WebMCP Agenten im Browser handeln laesst beschrieben; dieser Beitrag betrachtet die Platzierungsentscheidung, nicht den Mechanismus.
MCP (Model Context Protocol) definiert dagegen Server-seitige Endpoints, die ein Agent unabhaengig von jeder Browser-Session aufruft: Produktsuche, Warenkorb-Mutation, Bestellstatus, alles als aufrufbare Tools auf Ihrem Backend oder einer Middleware-Schicht. Was Agenten an solchen Endpoints konkret tun, haben wir in MCP-Endpoints und Storefront-Agent-Aktionen untersucht. Mehrere Anbieter konvergieren aktuell auf Server-seitige MCP-Bereitstellung, einen Trend, den wir in agent-lesbare Storefronts ueber Anbieter hinweg verfolgt haben.
Die Grenzentscheidung, konkret
- Wo Actuation laeuft. WebMCP (Browser): Innerhalb der geladenen Seite, client-seitig. MCP (Server): Auf einem dedizierten Backend-/Middleware-Endpoint.
- Was es braucht. WebMCP (Browser): Eine Seite, die Tools im DOM registriert. MCP (Server): Eine API-Oberflaeche unabhaengig von jeder offenen Seite.
- Session-Kontext. WebMCP (Browser): Nutzt, was der Shopper ohnehin geoeffnet hat (Warenkorb, Login). MCP (Server): Der Agent muss sich selbst authentifizieren und eine eigene Session halten.
- Governance. WebMCP (Browser): An das Rendering, die Marke und die Zugriffsregeln des Frontends gebunden. MCP (Server): An Backend-Berechtigungen, Rate-Limits und API-Vertraege gebunden.
- Passt am besten fuer. WebMCP (Browser): Unterstuetzende Aktionen innerhalb einer laufenden Shopping-Session. MCP (Server): Autonome oder geplante Agenten, die ohne Browser handeln.
Keine Ebene ersetzt die andere. Ein Agent innerhalb einer Browser-Session profitiert vom direkten DOM-Zugriff von WebMCP; ein Agent, der ganz ohne offene Seite arbeitet, eine Backend-Integration, ein geplanter Nachbestell-Job, braucht einen Server-seitigen MCP-Endpoint, der nicht davon abhaengt, dass eine Seite ueberhaupt gerendert ist.
Warum das Frontend diese Entscheidung weiterhin traegt
Egal welche Ebene ein Agent nutzt: Er liest weiterhin die strukturierten Daten, Produktattribute und markenkonforme Auszeichnung des Storefronts, um zu entscheiden, was „das in den Warenkorb legen" ueberhaupt bedeutet. WebMCP-Tool-Registrierung lebt im Frontend-Code. Server-seitige MCP-Endpoints brauchen weiterhin vom Frontend gepflegte Produkt- und Content-Daten, um korrekt zu antworten. Genau das ist die Betriebsfrage, um die unsere Agentic Frontend Management Platform gebaut ist: jemand muss beide Actuation-Oberflaechen konsistent, markenkonform und aktuell halten, unabhaengig davon, welches Protokoll ein einzelner Agent waehlt.
Was das fuer Haendler bedeutet
- Wenn Ihr Commerce-Team fuer Shopping-Assistenten innerhalb einer Session baut: starten Sie mit WebMCP-Tool-Registrierung auf Ihren wichtigsten Seiten.
- Wenn Sie Katalog-, Warenkorb- oder Bestelldaten fuer autonome Agenten ohne Browser bereitstellen: bauen Sie zuerst die MCP-Server-Endpoints.
- Die meisten Storefronts werden innerhalb von 12 bis 18 Monaten beides brauchen. Planen Sie die Datenschicht einmal, stellen Sie sie zweimal bereit.
FAQ
Ist WebMCP ein Ersatz fuer MCP? Nein. WebMCP uebernimmt browserseitige Actuation fuer Agenten innerhalb einer offenen Seite oder Session. MCP uebernimmt serverseitige Actuation fuer Agenten, die Ihr Backend direkt aufrufen, mit oder ohne Browser.
Was sollten Haendler zuerst bauen? Das haengt davon ab, woher Ihr Agent-Traffic heute kommt. Shopping-Assistenten innerhalb einer Session sprechen fuer WebMCP, Backend-Integrationen und autonome Agenten fuer MCP. Die meisten Teams brauchen am Ende beides.
Aendert das die Storefront-Architektur grundsaetzlich? Ja, beide Actuation-Oberflaechen haengen davon ab, dass dieselbe zugrunde liegende Frontend-Datenschicht, strukturierte Produktdaten, konsistente Auszeichnung und Markengovernance, korrekt bleibt. Das ist Frontend-Management-Arbeit, keine einmalige Protokoll-Integration.
Naechste Schritte
Wenn Sie eine konkrete Einschaetzung wollen, wo Ihr Storefront bei Browser- versus Server-Agent-Actuation steht, sprechen Sie mit uns.
CTA: Pruefen Sie, wie agent-faehig Ihr Storefront ist
Mehr von der Laioutr-Plattform
Ueber den Autor: Marcel Thiesies ist CEO & Co-Founder von Laioutr. Er schreibt ueber Frontend-Architektur, Agentic Commerce und den Aufbau composabler Storefronts ohne Replatforming-Risiko.