Die MCP-Ära: Wie das Model Context Protocol 2026 still und leise KI-Apps umgekrempelt hat

Anthropic hat das Model Context Protocol Ende 2024 veröffentlicht. Die meisten haben es unter „noch ein Standard“ abgelegt und sind weitergezogen. Achtzehn Monate später ist MCP die de-facto Verkabelungsschicht des KI-App-Stacks. Claude Code ist MCP-first. Cursor fährt mehrere Server in einer Session. Linear, Figma, Notion, GitHub, Slack und Stripe liefern alle offizielle Server aus. Das Protokoll hat gewonnen.

Das hier ist ein praxisnaher Einstieg plus Lagebericht. Was MCP auf Protokollebene ist, warum es frühere Standards geschlagen hat, welche kanonischen Server in Produktion laufen, was du damit anfangen solltest und wo es noch durchfällt.

MCP ist das Kabel, das endlich passt

Das Model Context Protocol lässt jeden KI-Client über einen Standard-Server mit jedem Tool oder jeder Datenquelle sprechen. Vor MCP war jede Integration Maßarbeit. Jeder Client erfand sein eigenes Tool-Format. Jedes Tool schrieb für jeden Client einen eigenen Adapter. Der kombinatorische Aufwand war erdrückend, und die meisten Builder gaben auf und hardcodeten ein paar Integrationen.

MCP hat das zusammengestaucht. Baue den Server einmal, und jeder MCP-Client kann ihn nutzen. Baue den Client einmal, und jeder MCP-Server ist erreichbar. Das richtige Primitiv zur richtigen Zeit, offen gesteuert, mit Anthropic als Treiber der Protokollarbeit, aber nicht als Eigentümer des Standards.

Was MCP auf Protokollebene wirklich ist

MCP ist JSON-RPC über einen Transport, mit einer kleinen Menge an Standard-Primitiven. Der Server stellt Ressourcen bereit (Daten, die das Modell lesen kann), Tools (Aktionen, die es aufrufen kann) und Prompts (Vorlagen, die der Nutzer auslösen kann). Der Client spricht auf jedem Server dieselben Methoden: list, read, call. Das ist die gesamte Abstraktion.

JSON-RPC ist langweilig, gut verstanden, mit curl debuggbar und funktioniert durch jede jemals gebaute Firewall. Die Aufteilung in Primitive gibt dem Modell genug Struktur, um zu erfassen, was ein Server kann, ohne den Server in ein Einheitsschema zu zwingen.

Die drei Transporte und warum sie wichtig sind

MCP läuft über drei Transporte: stdio, HTTP plus SSE und WebSockets. Stdio startet den Server als Kindprozess des Clients, der Standard für Desktop-Clients wie Claude Desktop. HTTP plus SSE betreibt den Server als Remote-Dienst, den der Client abfragt und von dem er streamt, die richtige Form für Cloud-MCP-Server. WebSockets decken den seltenen Fall ab, dass du von einem Remote-Server volles Duplex brauchst.

Der Transport ist meist eine Deployment-Entscheidung, keine Fähigkeitsfrage. Dieselbe Server-Logik läuft über alle drei. Ein Team kann lokal auf stdio prototypen und hinter seinem Auth-Gateway auf HTTP plus SSE ausliefern, ohne die Protokollschicht umzuschreiben.

Warum MCP gewonnen hat, wo frühere Standards verloren

ChatGPT-Plugins, Function-Calling-Specs und OpenAPI-for-LLMs wollten alle der Agent-Tool-Standard sein. Alle drei sind ins Stocken geraten. MCP hat gewonnen, weil es das richtige Primitiv zur richtigen Zeit mit der richtigen Governance gewählt hat.

ChatGPT-Plugins waren an einen Client und ein Abrechnungsmodell gebunden, und das Manifest setzte zustandslose HTTP-Endpunkte mit OpenAPI-Specs voraus, die fast kein echtes Produkt sauber anbietet. Function-Calling-Specs der einzelnen Labs waren Ein-Anbieter-Formate im Standard-Kostüm. OpenAPI-for-LLMs versuchte, ein Dokumentationsformat nachträglich zum Laufzeitvertrag umzubauen, und der Impedanz-Mismatch hat es erschlagen.

Das richtige Primitiv: Server statt Plugin

MCPs Entscheidung, die Integration als langlebigen Server mit typisiertem Vertrag zu bauen statt als zustandsloses Plugin-Manifest, ist die Architekturentscheidung, aus der alles andere folgt. Ein Server kann Datenbankverbindungen halten, Ressourcen cachen, Auth-Tokens verwalten, Antworten streamen und Updates ausliefern, ohne den Client zu brechen. Ein zustandsloses Plugin kann fast nichts davon. Echte Integrationen brauchen Zustand, Retries, Observability und Rate-Limit-Handling. Server tragen das. Plugins kämpfen dagegen.

Das richtige Timing: nach Tool-Use, vor dem Agent-Stack

MCP erschien genau dann, als Builder aufgehört hatten zu streiten, ob Tool Use wichtig ist, und anfingen zu streiten, wie man zehn Tools in einen Agenten verdrahtet, ohne sie bei jedem Release neu zu schreiben. Tool Use war geklärt. Das nächste Problem war Orchestrierung. MCP gab der Orchestrierungsschicht eine saubere Abstraktion.

Die Governance hat geholfen. Anthropic hat die Spec als Open Source veröffentlicht, die GitHub-Org geöffnet, von Tag eins an externe Beiträge akzeptiert und andere Labs ohne Erlaubnis Clients implementieren lassen. Bis Mitte 2026 hat OpenAI MCP-Support in seinen Assistants-Stack gebracht. Gemini unterstützt es über die Gemini API. Das große Zelt hat aus einem Nebenprojekt einen Standard gemacht.

Die kanonischen MCP-Server in Produktion

Eine kurze Liste erledigt die Schwerarbeit. Die meisten Agent-Stacks 2026 sind eine Kombination dieser neun.

Figma stellt Frames, Komponenten, Variablen und Layer-Bäume bereit, sodass das Modell einen Frame liest, wie ein Entwickler eine Spec liest. Linear stellt Issues, Projekte und Cycles bereit und macht aus Claude Code einen projektbewussten Coder. Notion stellt Seiten, Datenbanken und Blöcke bereit und wird damit zum universellen Kontextspeicher. GitHub stellt Repos, Issues, Pull Requests und Actions bereit, die kanonische Code-Kontextfläche. Slack stellt Channels, Threads und Suche bereit. Stripe stellt Kunden, Abos, Zahlungen und Metriken bereit, so lesen Finance- und Ops-Agenten die Bücher.

Postgres stellt Schemas, Tabellen und Abfragen mit Read- oder Read-Write-Scopes bereit. Filesystem stellt ein Sandbox-Verzeichnis bereit, so liest und schreibt Claude Code ein Repo. Browserbase stellt über MCP eine gehostete Chromium-Flotte bereit, so steuern Agenten einen Browser, ohne Infrastruktur zu verwalten. Neun Server, neunzig Prozent der Agentenarbeit.

Die MCP-first-Clients, die die Show schmeißen

Claude Code ist der kanonische MCP-Client. Jede Integration ist ein MCP-Server. Ein Tool hinzuzufügen heißt, eine Config-Datei zu bearbeiten und auf ein Server-Binary oder eine URL zu zeigen. Claude Desktop liefert dasselbe Modell mit einer UI, um Server pro Workspace zu konfigurieren. Cursor hat Anfang 2026 MCP-Support ergänzt und fährt jetzt mehrere Server in einer Session, weshalb dasselbe Cursor-Panel, das Code bearbeitet, auch einen Figma-Frame ziehen, ein Linear-Issue anlegen und Postgres abfragen kann.

Continue.dev ist MCP-first. JetBrains AI hat MCP-Support ergänzt. Zed hat MCP ausgeliefert. Jede IDE und jeder KI-Client, der ernst genommen werden will, liefert inzwischen MCP-Support, und Produkte ohne MCP-Story fühlen sich langsam alt an.

Was Designer wirklich mit MCP tun sollten

Hör auf, Figma zu screenshotten. Stelle deine Tools als MCP-Workspace bereit. Der Figma-MCP-Server gibt dem Modell echte Frame-Koordinaten, echte Variablen und echte Komponenten-Instanzen statt geratener Pixelwerte aus einem Bild.

Der größere Schritt ist der Aufbau eines einzigen MCP-Workspace. Verdrahte Figma, Notion und dein Design-Tokens-Repo als drei Server in Claude Code. Derselbe Prompt, der „baue diese Komponente nach Spec“ fragt, liest den Figma-Frame, holt die Begründung aus Notion, verweist auf die Token-Datei und schreibt den Code. Das ist das erste Mal, dass sich ein Designsystem in einem KI-Workflow tatsächlich wie ein zusammenhängendes Artefakt verhält. Dasselbe Muster gilt für Claude Skills, wo der Skill die Persona ist und MCP der Workspace.

Was Builder wirklich mit MCP tun sollten

Liefere für jedes interne Tool, das dein Team besitzt, einen internen MCP-Server aus. Richte Claude Code darauf aus. Sieh zu, wie derselbe Agent, der Code schreibt, anfängt, Operations zu fahren. Das Muster, das 2026 gewinnt, ist nicht „KI-Assistent für X“. Es ist „jedes Tool, das dein Team nutzt, als MCP-Server bereitgestellt, mit einem Client, der die Orchestrierung übernimmt“.

Du willst Hilfe, MCP in die Tools deines Teams zu verdrahten, ohne ein Quartal am Auth-Modell zu verlieren, oder einen internen MCP-Server-Stack auszuliefern, der in Produktion hält? Hire Brainy. ClaudeBrainy liefert ein MCP-Server-Template plus Prompt-Bibliotheken, und AppBrainy liefert komplette Produkt-Builds für Teams, die wollen, dass ihre Agenten einen echten Workspace teilen, keine Screenshots.

Der Bau ist nicht glamourös. Die meisten internen MCP-Server sind ein dünner Wrapper um eine bestehende API, plus Auth, plus eine Liste von Ressourcen und Tools. Ein paar hundert Zeilen Code, und das Deploy-Dashboard, der Error-Tracker, die Billing-Konsole oder das Admin-Panel des Teams wird zu einem weiteren Tool, das der Agent nutzen kann. Zehn Server später ist der Agent ein Teammitglied, kein Chatbot.

Wo MCP noch verliert

Latenz bei der Multi-Server-Orchestrierung, Auth-Komplexität und das Fehlen einer Mobile-Story sind die drei Stellen, an denen MCP noch durchfällt, und die Demos, die sie verstecken, sind die Demos, die man ignorieren sollte.

Latenz bei Multi-Server-Orchestrierung ist real. Ein Prompt, der in einem Zug Figma, Notion und Postgres anfasst, kann drei Roundtrips zahlen, bevor das Modell genug Kontext zum Antworten hat, und auf langsameren Transporten schiebt die summierte Wartezeit über fünf Sekunden. Caching hilft. Connection Pooling hilft. Nichts davon lässt die Latenz verschwinden.

Auth-Komplexität ist das zweite Loch. MCP standardisiert Auth nicht. Jeder Server wählt sein eigenes Modell: OAuth, API-Keys, Scoped Tokens, manchmal gar nichts. Fünfzehn Server in einen Client zu verdrahten heißt fünfzehn Credential-Stores, fünfzehn Refresh-Policies und fünfzehn Audit-Trails. Die meisten Teams unterschätzen das, bis zum ersten Mal ein Server mit Kundendaten in einen Nicht-Kunden-Kontext leakt.

Die Mobile-Story fehlt. MCP setzt einen langlebigen Client voraus, der lokale Prozesse starten, Netzwerkverbindungen halten und Server-Lebenszyklen verwalten kann. Nichts davon ist das mobile Ausführungsmodell. Mitte 2026 gibt es kein brauchbares MCP-on-iOS. Eine Handvoll Teams arbeitet an Remote-only-Profilen, aber das Protokoll ist noch nicht so weit.

Drei Fehlermodi, die gehypte MCP-Demos verstecken

Die meisten MCP-Reuegefühle 2026 lassen sich auf dieselben drei Löcher zurückführen.

Erstens. Die Auth-Handwedel-Demo. Der Präsentierende zeigt einen Server, der mit dem CRM eines Kunden verbunden ist, der Agent antwortet, Applaus. Die Auth war ein persönliches Token vom Demo-Account. Dasselbe Setup auf ein mandantenfähiges Produktionssystem zu richten heißt, Auth mit Scoped Credentials, OAuth-Flows und Mandantenisolation neu zu bauen. Fix: Wähle das Auth-Modell, bevor du den Server auslieferst, nicht danach.

Zweitens. Die Nur-lokal-Demo. Alles funktioniert auf dem Laptop des Präsentierenden, weil der Server per stdio mit dem lokalen Dateisystem und einer privaten Datenbank läuft. Nichts davon lässt sich an ein Team ausliefern, das HTTP plus SSE und geteilte Credentials braucht. Fix: Prototype auf stdio, liefere auf HTTP plus SSE hinter deinem Auth-Gateway aus und teste die Deploy-Story, bevor das Team ihr vertraut.

Drittens. Die Ein-Server-Demo. Der Agent nutzt einen Server wunderbar, der Präsentierende tut so, als sei Multi-Server-Orchestrierung nur eine weitere Config-Zeile. In Produktion bringen der zweite und dritte Server Latenz, Auth-Konflikte und Prompt-Verwirrung mit. Fix: Entwirf die Server-Menge als System, nicht als Liste. Dokumentiere die Grenzen.

Der rollenbasierte erste Schritt

Jede Rolle im Team hat einen anderen ersten Schritt mit MCP. Die Arbeit ist ungleich verteilt.

Das Muster. Designer und Frontend-Entwickler tragen den Workspace-Aufbau. Backend-Entwickler tragen den Server-Vertrag und das Auth-Modell. Gründer wählen die Spur.

FAQ

Was ist das Model Context Protocol?

MCP ist ein offenes Protokoll, das jeden KI-Client über einen Standard-Server mit jedem Tool oder jeder Datenquelle sprechen lässt. Der Server stellt Ressourcen, Tools und Prompts bereit. Der Client spricht JSON-RPC über stdio, HTTP plus SSE oder WebSockets. Anthropic hat die Spec Ende 2024 veröffentlicht, und Mitte 2026 ist es der de-facto Standard für Agent-Tool-Integration.

Ist MCP nur für Claude?

Nein. Cursor, Continue.dev, JetBrains AI, Zed und OpenAIs Assistants-Stack unterstützen alle MCP. Gemini unterstützt es über die Gemini API. Anthropic hat das Protokoll veröffentlicht, besitzt es aber nicht.

Muss ich meinen eigenen MCP-Server schreiben?

Für die kanonischen Tools wahrscheinlich nicht. Figma, Linear, Notion, GitHub, Slack, Stripe, Postgres, Filesystem und Browserbase liefern alle offizielle oder kanonische Server. Eigene schreibst du für interne Tools, individuelle Datenbanken und proprietäre APIs. Die meisten internen MCP-Server sind ein paar hundert Zeilen Code plus ein Auth-Modell.

Wie unterscheidet sich MCP von Tool Use?

Tool Use ist die modellseitige Fähigkeit, Funktionen mit strukturierter Ein- und Ausgabe aufzurufen. MCP ist das Protokoll, das definiert, wie Tools über beliebige Clients hinweg entdeckt, beschrieben und aufgerufen werden. Tool Use ist der Motor. MCP ist die Verkabelung. Der Einstieg zu Computer-Use-Agenten behandelt das dritte Standbein, wenn es keine saubere API zum Aufrufen gibt.

Wann ergibt MCP keinen Sinn?

Wenn du ein Tool, einen Client und eine hartkodierte Integration hast, die schon funktioniert. Der Gewinn liegt in der Welt mit mehreren Tools und mehreren Clients. Für einen Agenten und eine API reicht plain Tool Use völlig.

Der Wandel, den MCP wirklich freischaltet

MCP ist kein klügerer Agent. Es ist das Protokoll, das Agenten endlich einen Workspace teilen lässt, und die Produkte, die diesen Workspace als ihre Kernfläche behandeln, werden die nächste Runde gewinnen.

Die meisten Teams behandeln KI-Integrationen immer noch als Feature, das an ein Produkt drangeschraubt wird. Die Teams, die vorne wegziehen, behandeln den KI-Client plus eine Menge MCP-Server als den Workspace, und das Produkt ist das, was an den Rändern auftaucht. Die einen liefern einen weiteren Chat-Tab. Die anderen liefern ein Tool, das das Team wirklich nutzt. Derselbe Wandel zeigt sich im Vergleich der KI-Code-Editoren und im Teardown Claude 4.7 für Builder.

Wenn dein Stack dieses Quartal keine MCP-Story hat, werden die Agenten deiner Kunden dich überspringen. Wenn doch, behandeln diese Agenten dein Produkt wie ein Teammitglied. Wähle den Workflow. Liefere den Server aus. Verdrahte den Workspace.

Wenn du Hilfe willst, MCP in die Tools deines Teams zu verdrahten, ohne ein Quartal am Auth-Modell zu verlieren, oder einen internen MCP-Server-Stack auszuliefern, der in Produktion hält, hire Brainy. ClaudeBrainy liefert Skill-Packs und MCP-Server-Templates. AppBrainy liefert komplette Produkt-Builds für Teams, die wollen, dass ihre Agenten einen echten Workspace teilen, keine Screenshots.