MCP-Architektur 2026: Eine strategische Einordnung für IT-Entscheider

Auf dem Tisch lag bei einem Termin der letzten Wochen ein Angebot mit dem Slogan „Machen Sie Ihre Website agent-ready — in fünf Tagen“. Der IT-Leiter eines mittelständischen Dienstleisters fragte mich, was er von der Sache halten sollte. Im Pitch wurde WebMCP als Standard verkauft, MCP als „die nächste HTTP-Schicht des Internets“, und am Ende stand ein Festpreis. Auf der Liste der angeblichen Konsumenten standen ChatGPT, Claude und Gemini.

Die kürzeste ehrliche Antwort lautete: MCP ist real und produktiv einsetzbar. WebMCP ist eine spannende Vorabentwicklung, die in dieser Form heute aber nur Gemini in Chrome interpretieren kann. Wer beides in einen Topf wirft, verkauft etwas Reifes mit den Versprechen von etwas Experimentellem.

Dieser Beitrag richtet sich an IT-Entscheider, die zwischen Pitches und ernsthaftem Standard die Linie ziehen wollen. Statt einer weiteren technischen Tiefenanalyse — die in einem früheren Beitrag schon gezogen ist — eine Einordnung dessen, was MCP architektonisch wirklich bedeutet, wo Server-Netzwerke Wert liefern und wie der Reifegrad von WebMCP heute aussieht.

MCP als Standardisierung — wo wir 2026 stehen

Das Model Context Protocol ist seit Ende 2024 öffentlich, hat in fünf Quartalen eine ungewöhnlich schnelle Adoption erlebt und liegt mittlerweile in Spezifikation v2.1 vor. Auf der Anbieterseite unterstützen Anthropic, OpenAI, Google, Microsoft und mehrere kleinere Modellanbieter den Standard. Auf der Werkzeugseite gibt es heute tausende öffentlicher und privater MCP-Server, vom Filesystem-Wrapper bis zu professionellen SaaS-Integrationen.

Aus strategischer Sicht sind drei Eigenschaften relevant:

• Provider-agnostische Tool-Definition. Ein MCP-Server funktioniert mit jedem konformen Client. Investitionen in Server-Logik werden nicht durch einen Wechsel des Modellanbieters entwertet.
• Modulare Architektur. Anstatt einer monolithischen Integration kann eine Organisation viele spezialisierte Server betreiben, die ein Agent je nach Aufgabe orchestriert.
• Klare Trennung zwischen Modell und Werkzeug. Das Sprachmodell bleibt austauschbar, die fachliche Logik liegt in den Servern.

Diese drei Eigenschaften sind der eigentliche Hebel — nicht ein bestimmtes Werkzeug, nicht eine bestimmte Plattform.

Die drei Primitive, kompakt

Die Architektur lebt von einer bewusst kleinen Abstraktion. Drei Primitive, die im praktischen Einsatz unterschiedlich gewichtet werden.

• Tools — ausführbare Funktionen mit Argumenten. Das wirtschaftlich wichtigste Primitiv, weil hier die Geschäftslogik liegt. Schreiben, Lesen, Aktionen auslösen. Der Großteil aller produktiven MCP-Server konzentriert sich heute auf gut gemachte Tools.
• Resources — adressierbare Daten, die ein Client lesen kann. In der Theorie elegant für Read-Szenarien, in der Praxis bisher unterrepräsentiert. Wer einen eigenen Server konzipiert, sollte Resources mitdenken, sie sind aber nicht der Engpass.
• Prompts — vordefinierte Anweisungs-Templates. Die am wenigsten verbreitete Primitive. Für klar wiederkehrende Aufgabenmuster sinnvoll, in den meisten Setups eher Add-on als Kern.

Neuere Entwürfe (etwa SEP-1686 zur „Tasks“-Primitive für langlaufende asynchrone Operationen) sind in Diskussion, aber noch nicht im Standard verankert. Wer in einer Architektur entscheidet, sollte mit den drei stabilen Primitiven planen und Erweiterungen als Bonus betrachten.

Server-Komposition: Was realistisch ist

Die spannende strategische Aussage ist nicht „ein Server pro Anwendungsfall“, sondern die Komposition mehrerer Server zu einer agent-fähigen Plattform. In der Realität funktioniert das heute in drei Größenordnungen.

Klein — Editor- und Entwickler-Workspaces. Ein bis fünf Server (Filesystem, Git, Datenbank-Inspector, Build-Tools, ein eigener interner Server), gebündelt im Setup einer Entwicklerin. Sofort produktiv, geringer Pflegeaufwand, klare Wertgewinne.

Mittel — Team- und Abteilungs-Setups. Fünf bis fünfzehn Server, gemischt aus OSS-Servern, SaaS-Connectoren und ein bis drei eigenen Servern für interne Systeme. Verlangt eine zentrale Konfigurations-Disziplin (Repository-Sammlung der erlaubten Server, geteilte Auth-Patterns, gemeinsame Audit-Pflege).

Groß — Organisationsweite Plattformen. Mehr als zwanzig Server, oft mit eigenem Gateway, Mandantentrennung, Identitäts-Anbindung, zentraler Berechtigungssteuerung. Diese Ebene ist heute selten — wer dort ankommt, hat in der Regel eine eigene KI-Plattform und nicht nur „MCP eingeführt“.

Die Behauptung „200+ Tools verteilt auf spezialisierte Server“ ist in einzelnen Häusern realistisch, aber nicht der Maßstab, an dem sich jede Organisation messen sollte. Wer mit fünf bis acht gut gemachten Servern startet und sie sauber betreibt, hat den größten Wert pro Aufwand.

WebMCP: Was Anbieter versprechen vs. der echte Reifegrad

WebMCP ist der Bereich, in dem Pitches und Realität am stärksten auseinanderlaufen. Der Stand im Frühjahr 2026, sachlich:

• Standardisierungs-Status: W3C Draft Community Group Report vom 10. Februar 2026. Das bedeutet: ein in Erarbeitung befindlicher Vorschlag innerhalb einer W3C Community Group, kein Standard, kein Standards-Track-Dokument.
• Browser-Unterstützung: Chrome 146 in der Canary-Vorabversion, eine Origin-Trial-Phase mit Chrome 149. Edge folgt aus technischen Gründen sehr wahrscheinlich. Firefox und Safari beteiligen sich am Standardisierungsprozess, ohne Zeitplan.
• Agent-Unterstützung: Aktuell konsumiert nur Gemini in Chrome WebMCP-Tools direkt. ChatGPT und Claude bleiben außen vor, bis sie die Browser-API ebenfalls unterstützen — und das ist noch nicht der Fall.
• Browser-API: navigator.modelContext ist die zentrale Schnittstelle, aber nur in der genannten Chrome-Vorabversion zugänglich.

Die ehrliche Konsequenz für IT-Entscheider: Eine produktive Investition in WebMCP-Tools auf der eigenen Website hat heute eine erreichbare Nutzergruppe von Gemini-Nutzern in der jeweils passenden Chrome-Version. Das ist nicht „nichts“, aber es ist auch keine Massenwirkung. Wer in den nächsten zwölf Monaten eine konsumentenseitig wirksame Investition tätigen will, muss damit rechnen, dass die Verbreitung erst 2027 in den Bereich kommt, wo sie ohne ChatGPT- oder Claude-Unterstützung breit greift.

Das bedeutet nicht „WebMCP nicht beachten“. Es bedeutet: WebMCP gehört auf die Roadmap, nicht in das nächste Quartal. Eine vorbereitende Maßnahme — saubere Server-Architektur, klare Tool-Definitionen, gut strukturierte API-Schicht — ist immer sinnvoll. Eine konsumentenseitige Werbung, dass die Website „agent-ready“ sei, ist heute nur partiell zutreffend.

Was die Architektur strategisch bedeutet

Aus IT-Entscheider-Sicht sind vier Punkte über die Tech-Details hinaus relevant.

Lieferanten-Unabhängigkeit als Architekturentscheidung. Eine in MCP gebaute Tool-Schicht überlebt den Wechsel zwischen Modellanbietern. Das ist in einem Markt mit schnellen Preisbewegungen und sich verschiebenden Qualitätsverhältnissen eine echte Versicherung — keine theoretische.

Granularität wird wertvoller als Plattform-Bindung. Anstatt einer einzigen großen Integration entstehen viele kleine, klar abgegrenzte Server. Das verändert die Beschaffungslogik: weniger „eine Plattform für alles“, mehr „die richtige Sammlung spezialisierter Bausteine“.

Identitäts- und Berechtigungs-Layer werden zur Pflicht-Architektur. Mit jedem zusätzlichen Server steigt der Bedarf an einer zentralen Auth-Strategie. OAuth 2.1 mit Dynamic Client Registration ist hier der Pfad, in den die Standards zeigen. Wer das Identitätsthema nicht angeht, verliert Übersicht.

Beobachtbarkeit als wirtschaftliche Größe. Ohne strukturiertes Logging, Tracing und Audit über mehrere Server hinweg lässt sich weder die Wirkung messen noch Fehlverhalten erkennen. Das ist nicht „nice to have“, das ist Betriebsvoraussetzung.

Wo schon heute Wert entsteht

Eine kurze Sammlung der Anwendungsfelder, in denen MCP-basierte Setups 2026 messbar liefern.

• Wissensbasis-Lookups quer über interne Quellen (SharePoint, Confluence, eigene Dokumente) — der häufigste Einstieg, mit hohem Hebel.
• CRM- und ERP-Anbindungen für Lese-Operationen und kontrollierte Schreib-Aktionen — solide, wenn die Berechtigungen sauber geschnitten sind.
• Helpdesk- und Ticket-System-Integration — Tier-1-Anfragen vorqualifizieren, Tickets mit Kontext anlegen, Sachstände abfragen.
• Entwickler-Werkzeugketten — Repository-Operationen, Build-Status, automatisierte Test-Läufe. Hier hat MCP de facto die schnellste Reife erreicht.
• Datenanalysen mit kontrolliertem Datenbankzugriff — gut funktionierende Read-Tools mit klaren Mengen-Limits.
• Recherche- und Marktbeobachtungs-Workflows — strukturierte Web-Suche, kombiniert mit eigenen Quellen.

In diesen Bereichen ist die Investition heute wirtschaftlich tragbar, weil die Wertschöpfung sofort einsetzt und der Standard genug Reife hat, um Vertragslaufzeiten von zwei bis drei Jahren zu überstehen.

Wo der Markt noch wartet

Eine ebenso ehrliche Liste der Bereiche, in denen Anbieter heute Erwartungen wecken, die der Standard noch nicht trägt.

• Konsumenten-getriebene Agent-Browse-Szenarien — also der Fall, dass ein Nutzer-Agent eine fremde Website besucht, deren WebMCP-Tools entdeckt und für ihn nutzt. Heute nur über Gemini in Chrome real.
• Vollautomatische Transaktionen über Anbietergrenzen hinweg — buchen, bezahlen, vertraglich abschließen — verlangen zusätzliche Standards (Identität, Vertrauensanker, Beweissicherung), die parallel diskutiert, aber nicht final sind.
• Branchenübergreifend einheitliche Tool-Beschreibungen — die viel zitierte „Restaurant kann jetzt von jedem Agenten gefunden und gebucht werden“-Vision setzt eine semantische Standardisierung voraus, an der gerade erst gearbeitet wird.
• Mandantenfähige Agent-Netzwerke mit fein granularen Berechtigungen — der Standard erlaubt das, die Implementierungs-Praxis hinkt noch.

Wer in diesen Bereichen investiert, sollte das als Forschung und Vorbereitung betrachten — nicht als Roll-out mit erwartbarer Wirkung im aktuellen Geschäftsjahr.

Eine ehrliche Reifegrad-Einordnung

Eine knappe Bewertung der wichtigsten Bestandteile auf einer Skala „produktiv tauglich“, „pilotreif“, „experimentell“.

Diese Tabelle bewegt sich in den nächsten Quartalen, aber sie ist die ehrliche Momentaufnahme. Eine produktive Investitionsentscheidung sollte sich auf die ersten beiden Reifegrade konzentrieren.

Architektur-Empfehlungen für die nächsten zwölf Monate

Eine pragmatische Reihenfolge, die sich in der Beratungspraxis bewährt hat.

Erstes Quartal — Bestandsaufnahme und Pilot. Welche internen Systeme sollen für KI-Agenten zugänglich werden? Auswahl von ein bis zwei Pilot-Anwendungsfällen mit klarem Geschäftswert. Aufbau eines ersten internen MCP-Servers, vorzugsweise für eine Wissensbasis-Lookup-Funktion.

Zweites Quartal — Auth-Schicht und Beobachtbarkeit. Aufbau einer organisationsweiten Auth-Strategie (OAuth 2.1 mit DCR ist der empfohlene Pfad). Integration der Server-Logs in das vorhandene SIEM. Definition der Berechtigungs-Schnitte.

Drittes Quartal — Skalierung auf drei bis sieben Server. Erweiterung auf weitere Anwendungsfälle, jeweils mit klarer fachlicher Eigentümerschaft. Gemeinsame Namens- und Beschreibungskonventionen. Erste Erfahrungen aus dem Pilot in den Standard überführen.

Viertes Quartal — Konsolidierung und Roadmap-Update. Auswertung der gesammelten Erfahrungen. Entscheidung über die Ausweitung auf weitere Bereiche. Bewertung des dann aktuellen WebMCP-Standes — falls sich die Browser-Unterstützung verbreitert, kann eine erste konsumentenseitige Investition sinnvoll werden.

Dieser Pfad führt in einem Jahr zu einer produktiv tragenden MCP-Infrastruktur, ohne dass das Pferd vom Schwanz aufgezäumt wird.

Was ich für Sie entwickle

Mein Fokus liegt darauf, MCP-Setups dort zu bauen, wo sie heute schon wirtschaftlich tragfähig sind — nicht dort, wo sie laut Pitch sein sollen.

MCP-Server für interne Systeme — schlanke Server für CRM-, ERP-, Wissensbasis- oder Ticket-Anbindungen, mit klaren Tool-Schemata, sauberer Auth und differenzierten Berechtigungen.

Architektur-Konzepte für Mehrserver-Setups — gemeinsame Konventionen für Namen, Beschreibungen, Fehler-Codes, Logging. Aufbau eines internen Gateway-Layers, wenn die Anzahl der Server eine zentrale Steuerung sinnvoll macht.

Auth-Architektur mit OAuth 2.1 — produktiv tragfähige Auth-Setups für Multi-User-Szenarien, inklusive Token-Lifecycle, Refresh und Audit-Schnittstelle.

Beobachtbarkeits-Konzept — strukturiertes Logging, Tracing über Tool-Calls hinweg, Alerts und Health-Checks. Damit Server in Produktion nicht im Blindflug laufen.

Compliance- und AI-Act-Begleitung — Verarbeitungsverzeichnis, Datenschutz-Folgenabschätzung, Kennzeichnung, Risiko-Klassifikation der Anwendungsfälle.

WebMCP-Vorbereitung — wo es heute schon sinnvoll ist, die eigene API-Schicht so zu strukturieren, dass eine spätere WebMCP-Anbindung mit geringem Aufwand möglich ist. Aber ohne Versprechen einer Konsumentenwirkung, die der Standard heute noch nicht trägt.

Der pragmatische Einstieg ist meist ein erster interner Server für einen klar abgegrenzten Anwendungsfall. Aus dieser Erfahrung lassen sich die Standards und Patterns für weitere Server ableiten — eine echte Plattform, nicht ein einzelnes Tool.

Fazit

MCP ist 2026 ein ernstzunehmender Industriestandard mit klarer Reife in den Bereichen, die wirtschaftlich heute am wichtigsten sind: produktive Server für interne Anwendungsfälle, breite Client-Unterstützung, ausgereifte Tools-Primitive, etablierte Transport-Schichten. Die Investition in eine MCP-basierte Tool-Schicht ist unter den heute verfügbaren Optionen die wahrscheinlich beste Versicherung gegen Lieferanten-Abhängigkeit und gegen Modell-Wechsel.

WebMCP ist eine spannende Entwicklung, aber kein Standard, auf den eine konsumentenseitig wirksame Investition heute aufbauen sollte. Eine vorbereitende Architektur, die saubere Tool-Beschreibungen und eine klare API-Schicht etabliert, ist sinnvoll — eine Marketing-Aussage „unsere Website ist agent-ready“ ist heute noch überspitzt.

Die ehrliche Empfehlung für IT-Entscheider lautet deshalb: MCP in den internen Anwendungsfällen jetzt aufbauen, in den ersten zwölf Monaten eine produktive Plattform mit drei bis sieben Servern entwickeln, die Auth- und Beobachtbarkeitsschicht ernsthaft mitdenken — und WebMCP auf die Roadmap nehmen, ohne in den nächsten Quartalen eine breite Konsumentenwirkung zu erwarten. Wer diesen Pfad geht, hat in zwölf Monaten eine Infrastruktur, die auf der Welle reitet — und nicht von ihr überrollt wird.