
No MCP, no Party: Warum kein Unternehmen mehr an MCP vorbeikommt
TL;DR: „Wenn dein Produkt nicht im Workflow des Assistenten ist, ist es nicht im Workflow des Nutzers. MCP ist nicht mehr Feature, sondern Distribution. Jedes Unternehmen – SaaS oder nicht – braucht jetzt eine MCP-Strategie."
— Till Freitag„No MCP, no party."
Ich verbringe inzwischen die Hälfte meines Tages in Claude Cowork, Claude Code oder Codex. Das sind alles Varianten desselben Musters: ein Assistent, der die Arbeit in meinen Tools erledigt – damit ich nicht selbst dorthin muss.
Die Gleichung ist simpel:
Wenn dein Produkt nicht im Workflow des Assistenten ist, ist es nicht im Workflow des Nutzers.
Und das gilt nicht mehr nur für klassisches SaaS. Es gilt für jede interne Plattform, jedes ERP, jedes Bestellsystem, jede Datenbank. Wer den Sprung verpasst, wird unsichtbar.
MCP ist kein Feature mehr. Es ist ein Distributionskanal.
Das Model Context Protocol ist nicht „noch eine API". Es ist die dünne Standardisierungsschicht, durch die jeder Major-AI-Client mit jedem Tool reden kann. Wer schon mit MCP gearbeitet hat, kennt die Grundlagen – hier geht es um die strategische Konsequenz.
- Anthropic hat es gestartet
- OpenAI hat es übernommen
- Google, Microsoft, Salesforce, Atlassian, Notion ziehen mit
- Es ist der De-facto-Industriestandard geworden
Was als Integrationsprotokoll begann, ist zu etwas Größerem geworden: einem neuen Vertriebskanal, der noch verteilt wird. So wie der App Store 2008 oder Chrome-Extensions 2012.
Was Lemlist gerade demonstriert
Vor zwei Tagen berichtete Charles Tenot von Lemlist: 700 Kunden nutzen Lemlist wöchentlich über Claude – das sind 3 % ihres Bestands, ohne klassisches Marketing. Einfach weil sie früh einen MCP-Server ausgeliefert haben.
Das ist kein Marketing-Gag. Das sind Kunden, die ihr Tool nie wieder direkt öffnen, weil der Assistent es für sie tut.
Für Unternehmen, die diesen Schritt nicht gegangen sind, läuft gerade still ein Wechsel: Nutzer migrieren zu dem Tool, das ihre KI bereits steuern kann. Nicht weil die Alternative besser ist. Sondern weil sie überhaupt existiert.
Was das für CEOs bedeutet
Ich sage es so deutlich, wie ich kann: Als CEO würde ich aktuell nur Entwickler einstellen, die meine Systeme integrieren und für Agenten öffnen können.
Das ist keine Übertreibung. Es ist die nüchterne Konsequenz aus drei Beobachtungen:
- Jede Software wird in den nächsten 24 Monaten von einem Agenten aus bedient werden – intern wie extern.
- Klassische UI-Arbeit verliert relativ an Wert. Eine Schaltfläche, die kein Agent finden kann, bringt nichts.
- MCP-fähige Systeme werden zur Standardausstattung – wer das nicht liefert, fliegt aus Stack-Entscheidungen raus.
Die neue Hiring-Checklist
| Skill | 2023 | 2026 |
|---|---|---|
| React/Frontend | Pflicht | Nice to have |
| REST/GraphQL APIs | Pflicht | Pflicht |
| MCP-Server bauen & betreiben | Unbekannt | Pflicht |
| Agent-Skills + Tool-Schemas | Unbekannt | Pflicht |
| Klassische Integrations-Engineering | Pflicht | Pflicht |
| Auth & Permission-Modelle für Agenten | – | Pflicht |
Wenn deine nächste Stellenausschreibung „React Developer" heißt – schreib sie um. Du suchst Integration Engineers, die Systeme für Agenten öffnen.
Was das für Entwickler bedeutet
Wenn du heute Entwickler bist und dich fragst, worauf du dich spezialisieren sollst: Konzentriere dich auf MCP.
Nicht weil es das spannendste Thema ist (das auch). Sondern weil es das knappste Skillset im Markt ist.
Was „auf MCP konzentrieren" konkret heißt
- Server bauen: TypeScript- oder Python-SDK lernen, eigene Tools, Resources und Prompts modellieren
- Bestehende APIs kapseln: Fast jede REST-API kann als MCP-Server bereitgestellt werden – wer das schnell kann, ist Gold wert
- Auth & Permissioning verstehen: OAuth, scoped tokens, dynamic client registration – das ist der unsexy, aber entscheidende Teil
- Skills schreiben: Ein MCP-Server ohne gute SKILL.md ist halb so wertvoll. Siehe auch Agent Skills werden Industrie-Standard
- Hosting kennen: Wo läuft der MCP-Server in Production? Cloudflare Workers, Supabase Edge Functions, Railway – jede Plattform hat eigene Trade-offs
Das ist kein Nischenwissen mehr. Das ist die nächste Schicht von Backend-Engineering.
Die drei Szenarien für dein Unternehmen
Szenario 1: Du bist SaaS
Pflichtprogramm. Wenn dein Produkt in 12 Monaten noch im Stack deiner Kunden sein soll, brauchst du einen MCP-Server – idealerweise mit OAuth, Multi-Tenant-Auth und sauber dokumentierten Tools.
Mindestens für die 3 wichtigsten Workflows deiner Top-Personas. Lemlist hat genau das gemacht – Sequenz starten, Lead hinzufügen, Reply-Status checken. Mehr nicht. Reicht.
Szenario 2: Du bist klassisches Unternehmen mit eigenen Systemen
Auch Pflichtprogramm – nur intern. Dein ERP, dein internes CRM, dein DMS, deine Datenbank: Solange dort kein MCP-Server liegt, kann dein eigenes Team nicht mit Claude oder Codex daran arbeiten. Das ist verschenkte Produktivität.
Wir bauen für Kunden gerade genau das: Internal MCP Servers, die hinter SSO sitzen und nur den eigenen Mitarbeitern Agent-Zugriff auf Firmendaten geben. Kein externes Risiko, voller interner Hebel.
Szenario 3: Du baust gerade etwas Neues
Glückwunsch, du hast den einfachsten Pfad. Bau MCP von Tag 1 mit ein. Dann ist dein Produkt von Anfang an Teil des Agenten-Ökosystems – statt nachträglich angeflanscht.
Der Distributionskanal, der noch nicht verteilt ist
Das ist der entscheidende Punkt: MCP ist gerade in der Phase, in der App Stores 2009 oder das Web 1995 waren. Die Plätze auf der Bühne werden gerade verteilt.
Es gibt:
- Verzeichnisse wie mcp.so und glama.ai/mcp/servers, die zu Discovery-Layern werden
- Native Marketplaces in Claude, ChatGPT und Cursor
- Default-Listen in Tools wie Lovable, die festlegen, welche MCPs „eingebaut" sind
Wer jetzt da ist, wird in zwei Jahren als Standard wahrgenommen. Wer wartet, kämpft sich später durch ein überfülltes Verzeichnis.
Was du diese Woche tun solltest
Egal ob CEO, CTO oder Entwickler – das hier ist die Liste, mit der ich aktuell jedes Gespräch beginne:
- Audit deines Stacks: Welche deiner Systeme haben heute schon MCP-Server? Welche brauchen welche?
- Wähle den ersten MCP-Server aus: Nicht den größten, den wichtigsten – das System, das deine Leute am häufigsten anfassen müssen
- Setze einen Agenten drauf: Claude Desktop, Claude Code oder Codex – einer reicht, um den Produktivitätssprung sichtbar zu machen
- Schreibe die Stellenausschreibung um: „Backend Engineer mit MCP-Erfahrung" oder „Agent Integration Engineer" – nicht „Senior Fullstack"
- Plane das Distribution-Listing: Sobald dein MCP-Server läuft, gehört er in mcp.so, in den Claude-Marketplace und auf eure eigene Docs-Seite
Fazit: Die zweitbeste Zeit ist jetzt
MCP ist kein Trend, kein Hype-Cycle, kein „mal abwarten". Es ist Infrastruktur. Und Infrastruktur belohnt die, die früh da sind, brutal – und bestraft die, die warten, genauso brutal.
Die beste Zeit, deinen MCP-Server zu launchen, war gestern. Die zweitbeste ist heute.
Wenn dein Assistent dein Produkt nicht erreicht, ist dein Produkt nicht im Spiel.
Du willst wissen, wie ein MCP-Server für dein System konkret aussieht – ob als SaaS-Produkt oder als interne Plattform? Lass uns reden →








