Das MCP-Paradox: Wer agent-friendly wird, kommoditisiert sich selbst

Wer Notion seit drei Monaten fast ausschließlich über den MCP-Server nutzt, öffnet die eigentliche Oberfläche vielleicht einmal die Woche — meistens nur, um etwas zu bestätigen, das ein Agent schon angelegt hat. Was vorher Notion-Stickiness war (die schöne UI, die durchdachten Templates, die Block-Mechanik), ist irrelevant geworden. Der Vergleichsmaßstab ist nicht mehr “wie gut ist Notion”, sondern “wie gut ist der Notion-MCP-Server, und ist er bereits in den Default-Connectoren von Claude, Cursor oder ChatGPT?”.

Das ist die unbequeme Wahrheit, die in der aktuellen MCP-Euphorie untergeht: Genau dieselbe Eigenschaft, die ein SaaS-Produkt für Agents wertvoll macht, eine perfekte, vollständige, idempotente API plus MCP-Server, macht es gleichzeitig austauschbar.

Jason Lemkin hat in seinem SaaStr-Artikel vom April 2026 die Checkliste für agent-friendly APIs sauber zusammengefasst: MCP-Server, Agent-Toolkits für die gängigen Frameworks, /llms.txt, executable Errors mit did_you_mean und hint, idempotente Mutations, Webhooks für jeden State-Change, Skills-Catalog. Wer das nicht hat, ist 2026 “im Agent-Layer effektiv unsichtbar”. Lemkin hat recht. Aber er erzählt nur die halbe Story.

Was MCP mit dem klassischen SaaS-Moat-Stack macht

Der klassische SaaS-Moat besteht aus sechs Schichten:

Daten-Lock-in — deine Daten liegen bei uns
Workflow-Lock-in, dein Team arbeitet in unserer UI
Integrations-Lock-in, andere Systeme hängen an uns
Netzwerkeffekte, andere nutzen uns auch
UX & Brand, das Erlebnis ist gut, der Name vertraut
Switching-Cost. Migration ist schmerzhaft

MCP greift gezielt Schicht 2 und 5 an und schwächt Schicht 6. Wenn der Workflow im Agent stattfindet, nicht in der UI, sieht niemand mehr die UX. Niemand erlebt mehr die Marke. Niemand vergleicht mehr Block-Editoren oder Drag-and-Drop-Mechaniken. Was der Agent vergleicht, ist die API-Vollständigkeit, die Latenz und die Verfügbarkeit eines Connectors.

Und wenn Lemkins Checkliste konsequent umgesetzt ist, generöse Rate Limits, idempotente Endpoints, saubere Webhooks, machine-readable Discovery, dann ist auch Schicht 1 angeschlagen: Datenexport ist trivial geworden. Was vorher ein 6-monatiges Migrationsprojekt war, kann ein Agent in einem Wochenend-Run durchziehen.

Was MCP nicht angreift: Daten-Schwerkraft, die regulatorisch oder physisch verankert ist (Schicht 1 in vertikalen Kontexten), echte Netzwerkeffekte (Schicht 4) und tief in die Welt aus Atomen verankerte Integrationen (Schicht 3). Das ist der Schutzwall, den wir in Death by Clawd als “physische Atome-Schicht” beschrieben haben — und er hält weiter.

Die Moat-Sortierung 2026: Wer ist gefährdet, wer ist resilient?

Das ist die Linse, die für Investoren in DACH B2B Software die nächsten 24 Monate entscheidet:

Hochgradig MCP-kommoditisierungs-gefährdet 🔴

Das Muster: Schöne UI über generischer Datenstruktur. Der Wert lag in der Workflow-Erfahrung, nicht in den Daten oder Integrationen.

Knowledge & Productivity: Notion, Confluence, Coda, generische Wikis
Project Management: Asana, Linear, ClickUp, generisches Kanban
Standard-CRM ohne Vertikal-Tiefe: wenn der Use Case “Pipeline tracken” lautet, nicht “Branchenprozess abbilden”
Generische Ticketing-Tools: Zendesk-Lite-Klone, basic Helpdesk
Standard-HR/Performance-Tools: ohne Payroll-Verankerung oder regulatorischer Tiefe

Genau die Kategorien, in die seit 2018 die meisten VC-Wachstumsdollars geflossen sind. Wer hier sein PE-Investment sitzen hat, sollte spätestens jetzt fragen, wo der echte Moat jenseits der UX liegt.

Teilweise gefährdet 🟡

Das Muster: Moat existiert, aber liegt nicht da, wo das Pricing ihn vermutet.

Communication-Tools wie Slack/Teams: Netzwerkeffekt schützt, aber nur solange der Agent nicht selbst zum besseren Channel wird
Email-Marketing & Sales Engagement: Daten sind portabel, der Wert liegt in den Templates und der Lieferbarkeits-Reputation
Document-Signing: Switching-Cost ist real, aber nicht hoch — und der Use Case ist trivial agent-fähig

MCP-resistent 🟢

Das Muster: Daten-Schwerkraft + Regulatorik + physische Verankerung. Hier wirkt MCP multiplizierend, nicht substituierend.

ERP, vertikales ERP, MES: Daten verlassen das System nicht freiwillig, der Prozess ist regulatorisch verankert, die Implementierung berührt physische Welt (Maschinen, Lager, Produktion)
Payments & Banking: Stripe ist das Lehrbuch-Beispiel — die Rails sind der Moat, nicht die API. Stripe darf seinen MCP-Server perfekt bauen, weil das Pricing über Transaktions-Volumen läuft, nicht über Seats
Identity & Compliance: Migration ist real teuer, regulatorisch geprüft, mit Audit-Trails belegt
Vertikale Spezialsoftware: Construction Tech (siehe Nemetschek/HCSS in KW16), Energy Management (PSI Software), Connected Safety, Hospitality-Connectivity, alles Kategorien, in denen kein Agent das Backend-Modell sinnvoll nachbauen kann
Industriespezifische Datasets: wenn der Wert im proprietären, jahrelang trainierten Modell liegt, nicht in der API

SaaSpocalypse-Test 2.0: Ein Tool ist MCP-resilient, wenn die Antwort auf “kann mein Agent das Backend in 6 Monaten replizieren oder ersetzen?” ein klares Nein ist — nicht wegen der Software-Komplexität, sondern wegen Daten, Regulatorik oder physischer Verankerung.

Das Stripe-Salesforce-Notion-Triangle

Drei Datenpunkte, die das Paradox illustrieren:

Stripe hat alles aus Lemkins Checkliste umgesetzt — MCP-Server, Agent-Toolkit für vier Frameworks, Skills-Catalog, /llms.txt, restricted API Keys mit granularen Rechten. Stripe wird dadurch nicht austauschbarer. Warum? Weil die Rails der Moat sind, nicht das Interface. Wer Stripe ersetzen will, muss Banking-Lizenzen, Acquirer-Beziehungen und Risk-Modelle ersetzen, nicht eine API.

Salesforce hat mit Headless 360 + MCP einen brutalen Sprung gemacht (siehe Lemkins Beispiel: er führt die Plattform headless, kein Mensch loggt sich mehr ein). Salesforce ist weiterhin schwer zu ersetzen — aber nicht wegen der UI. Sondern wegen der 27 Jahre Integrations-Tiefe, der vertikalen Datenmodelle und der Ökosystem-Schwerkraft (AppExchange, Implementation Partners, Trailhead-Skills). Die UI ist kommoditisiert. Der Datenkern ist es nicht.

Notion ist das Lehrbuch-Beispiel der Gegenseite. Schöne UI, generische Block-Datenstruktur, MCP-Server seit 2024 verfügbar. Sobald der Agent die Schnittstelle ist, wird der Vergleich brutal: “Hat dein Knowledge-Base-Tool einen MCP-Server mit ähnlicher Capability?” Antworten: Confluence ja, Coda ja, sogar Obsidian via Community-Server. Die Notion-Marke schützt nicht mehr, weil niemand die Marke mehr sieht.

Das ist nicht hypothetisch. Das ist ein konkretes Nutzungsmuster, das sich seit Q1 2026 bei Early Adopters durchsetzt.

Das Pricing-Paradox: Wenn ein MCP-Server zehn Seats ersetzt

Die technische Kommoditisierung durch MCP hat eine unmittelbare Business-Model-Konsequenz, die über die Moat-Diskussion hinausgeht: Seat-Based Pricing, das Fundament von 80% aller SaaS-Geschäftsmodelle, wird strukturell unterlaufen.

Das Szenario ist bereits Realität: Ein Team, das bisher zehn Notion-Seats à $10/Monat brauchte, braucht heute einen MCP-Server-Zugang und einen Agent, der die Arbeit koordiniert. Die Notion-API verarbeitet dieselben Requests — aber statt $100 MRR steht im besten Fall ein einziger API-Zugang zu Buche. Das ist keine hypothetische Bedrohung, das ist die Mathematik der Seat Compression, angewandt auf den MCP-Layer.

Was das für SaaS-Pricing bedeutet:

Pricing-Modell	Status quo	Unter MCP-Druck
Per-Seat	80% aller SaaS-Tools	Kollabiert, wenn Agents Seats ersetzen
Usage-Based (API Calls, Storage)	Wachsend, aber oft zu granular	Überlebt, aber Race-to-the-Bottom bei Commodity-APIs
Outcome-Based	~15% (wachsend auf 40% laut Deloitte)	Einziges Modell, das den Wert korrekt abbildet
Platform/Transaction Fee	Stripe, Adyen, Payment-Rails	MCP-resistent — Volumen steigt sogar

Die entscheidende Frage ist nicht “haben wir einen MCP-Server?”, sondern “wie bepreisen wir den Wert, den unser Tool liefert, wenn die Delivery über einen Agent läuft statt über eine UI mit Seat-Login?”

Drei Muster, die sich abzeichnen:

Outcome-Based Pricing: Nicht “10 Seats à $20”, sondern “pro erfolgreich verarbeiteter Transaktion”, “pro generiertem Report”, “pro geschlossenem Ticket”. Salesforce experimentiert damit über Agentforce — $2 pro gelöster Konversation statt $150/Seat/Monat. Das ist ein fundamentaler Bruch mit dem Seat-Modell.
Agent-Seat-Pricing: Ein neuer Seat-Typ — nicht für Menschen, sondern für Agents. Höherer Preis, höheres Rate Limit, eigene Permissions. Notion, Linear und Asana testen Varianten davon. Das Problem: Es fühlt sich an wie ein Pflaster auf einer strukturellen Wunde.
Value-Layer-Pricing: Der Preis koppelt sich an die Schicht, die tatsächlich nicht substituierbar ist. Stripe bepreist Transaktionen (nicht API-Calls). Ein vertikales ERP könnte “pro verarbeiteter Auftragsposition” bepreisen — egal ob ein Mensch oder ein Agent die Eingabe macht. Das ist die nachhaltigste Variante, aber erfordert ein Umdenken von “wir verkaufen Software” zu “wir verkaufen Geschäftsergebnisse”.

Die Investment-Implikation: Portfolio-Companies, die ihr Pricing nicht proaktiv auf Agent-Szenarien umstellen, werden doppelt getroffen — technisch durch MCP-Kommoditisierung und wirtschaftlich durch Seat-Erosion. Wer dagegen frühzeitig auf Outcome- oder Value-Layer-Pricing umstellt, kann den MCP-Multiplier nutzen: Mehr Agent-Traffic = mehr Outcomes = mehr Revenue, selbst wenn kein einziger Mensch die UI öffnet.

Was als neuer Moat entsteht

Wenn UX und Workflow als Moat verschwinden, entstehen neue Kategorien — und das ist die spannende Investment-Frage:

MCP-Connector-Distribution. Wer ist in den Default-Listen von Claude, Cursor, Copilot, Gemini? Das wird der neue “App-Store-Ranking”-Moat. Wer früh in diesen Listen ist, hat einen massiven Cold-Start-Vorteil.
Skills-Catalogs als opinionated Workflow-Layer. Lemkins Punkt 10 — Skills sind keine API-Beschreibung, sondern eingefrorene Best-Practice-Workflows. Wer hier früh seinen branchenspezifischen Skill-Catalog publiziert, definiert die Sprache, in der Agents über die Domäne sprechen.
Agent-native Datenmodelle. Nicht “wir haben einen MCP-Server vor unsere REST-API gespannt”, sondern “unsere Datenmodelle und Workflow-Logik sind so gebaut, dass der Agent unsere Opinionatedness mitnimmt — nicht nur unsere Tabellen”. Der Punkt, an dem agent-native gebaute Systeme strukturell vorne liegen.
Vertical-spezifische LLM-Fine-Tunes auf proprietären Daten. Generische Foundation Models reden nicht ERP-Deutsch, kennen keine WEKA-Vorschriften und verstehen den Unterschied zwischen Auftragsbestätigung und Lieferschein nicht. Wer 4.000+ Vertikal-Kunden hat (siehe enventa-Verticals: Mode, SHK, Elektro, Technischer Großhandel), sitzt auf Trainingsdaten, die kein Hyperscaler hat.

Die DACH-Investment-Implikation

Für PE/VC im DACH B2B Software heißt das konkret:

Yellow Flags in Portfolio-Companies:

Wer hat seinen Moat primär in der UX angesiedelt?
Wer hat eine generische Datenstruktur ohne vertikale Tiefe?
Wer hat Switching-Costs vor allem aus User-Adoption gebaut, nicht aus Daten oder Integrationen?
Wer hat eine API, die Lemkins Checkliste nicht erfüllt — und wird deshalb als erstes ersetzt, sobald ein Agent-fähiger Wettbewerber auftaucht?
Wer hält an Per-Seat-Pricing fest, obwohl die Agent-Nutzung bereits Seats kannibalisiert?

Green Flags:

Vertikale Tiefe, regulatorische Verankerung, physische Anbindung
Daten, die zwar exportierbar sind, aber außerhalb des Kontexts ihren Wert verlieren
Etablierte Integrations-Schwerkraft mit anderen Mission-Critical-Systemen
Aktive MCP-Strategie nicht als Pflichtübung, sondern als Konsolidator-Move (eigener Skills-Catalog, eigene Default-Listen-Präsenz)
Pricing-Modell, das vom Agent-Traffic profitiert statt darunter zu leiden

Konsolidator-Kandidaten: Genau die Kategorien aus den Mid-Market-Mustern der Weekly Digests — vertikales ERP, Construction Tech, Industrial Software, Compliance/Legal Tech. Diese Kategorien profitieren zweifach: einmal vom MCP-Multiplier (eigene Customers werden produktiver), einmal vom Konsolidierungsdruck im darüber liegenden Layer (Notion-artige Tools fallen weg, deren Workflows wandern in die Vertikal-Suiten).

Perspektive 🎯

Der MCP-Server ist nicht das Ziel. Er ist der Hygiene-Faktor. Wer 2026 keinen hat, ist draußen. Aber wer denkt, “MCP-Server gebaut, fertig, jetzt sind wir agent-ready”, hat das eigentliche Spiel nicht verstanden. Die Frage ist nicht “haben wir MCP?”, sondern “wo liegt unser Moat trotz MCP — und wie wird er durch MCP eher größer oder eher kleiner?”
Notion ist der unbequemste Datenpunkt. Notion war eines der Tools mit dem stärksten “Brand Love” der letzten fünf Jahre. Communities, Templates, eine ganze Creator-Ökonomie. Drei Monate konsequente MCP-Nutzung reduzieren das auf null. Wenn das mit Notion passiert, passiert es mit hundert anderen Tools auch.
Stripe ist die Antithese — und das Lehrstück. Stripe darf MCP umarmen, weil Stripe nicht über Workflow-Lock-in lebt, sondern über Banking-Rails und Risk-Modelle. Jedes SaaS-Investment, das nicht erklären kann, was sein “Stripe-Äquivalent” ist (welcher nicht-substituierbare Layer trägt das Geschäft, wenn die UI verschwindet?), ist im Risiko.
Pricing ist der zweite Lackmus-Test neben dem Moat. Wer Per-Seat verkauft und gleichzeitig einen perfekten MCP-Server baut, sägt am eigenen Ast. Die Gewinner sind diejenigen, deren Pricing-Modell mit der Agent-Nutzung skaliert — nicht gegen sie. Outcome-Based und Value-Layer-Pricing sind keine Nice-to-haves mehr, sondern Überlebensfragen.
Für PE-backed B2B Software in DACH ergibt sich eine paradoxe Bewertungslogik: Aggressive MCP-Strategie steigert den Wert vertikaler, regulatorisch verankerter Software (weil sie multipliziert wird) und senkt den Wert generischer Workflow-Tools (weil sie kommoditisiert werden). Die nächste Welle der DACH-Software-Konsolidierung wird genau dieser Logik folgen — und sie hat in KW15 und KW16 bereits begonnen, nur wurde es noch nicht so benannt.

Die Frage, die jeder CEO und jeder Investor diese Woche im Kalender haben sollte, ist nicht “haben wir einen MCP-Server?”. Sondern: “Wenn unser MCP-Server perfekt wäre und unsere UI nie wieder geöffnet würde — was bleibt von unserem Moat? Und wenn die ehrliche Antwort ‘wenig’ ist, wo investieren wir die nächsten 18 Monate, um das zu ändern?”

Das ist die Verschärfung der These aus Agent statt Anwender. Dort wurde gesagt: Die UI verschwindet. Hier ist die Konsequenz: Mit der UI verschwindet ein erheblicher Teil des klassischen SaaS-Moats — und nur wer seinen Moat eine Schicht tiefer hat, gewinnt im Agent-Zeitalter.

Quellen & Weiterführendes

Jason Lemkin: The Simplest Way to Make Your Product More Agentic (SaaStr, April 2026)
Stripe Building with AI Documentation
Salesforce Headless 360 Launch (TDX 2026)
Deloitte: SaaS AI Agents & Pricing
The Playbook: Agent statt Anwender | Death by Clawd | Tech Due Diligence 2.0 | Vibe Coding