Letzte Woche hat TikTok auf der TikTok World 2026 seinen eigenen MCP-Server für Ad-Automation gelauncht. Eine Woche davor GitHub, davor Notion, davor Productive. Jeder größere SaaS-Anbieter shippt mittlerweile sein eigenes Model Context Protocol Endpoint — und niemand redet darüber, was das für IT-Abteilungen in deutschen Mittelständlern bedeutet. Wir sehen es bei unseren Kunden jeden Tag: Aus einem Agenten-Experiment werden in zwei Quartalen zwanzig MCP-Connectoren. Wir nennen das MCP-Sprawl, und 2026 wird das Jahr, in dem er jeden trifft.
Was ist MCP überhaupt — kurz und ehrlich
Model Context Protocol ist ein offener Standard, den Anthropic Ende 2024 vorgestellt hat. Die Idee: Statt jedes LLM mit jeder API einzeln zu verheiraten, definiert MCP ein einheitliches Protokoll. Ein Agent spricht MCP, ein Server spricht MCP, fertig. Auf dem Papier ist das die saubere Antwort auf das Integrations-Chaos der letzten zwei Jahre.
In der Praxis ist es 2026 etwas anderes geworden. Anthropic hat den Standard gestartet, aber adoptiert haben ihn alle: OpenAI, Google, Microsoft, AWS Bedrock — und seit ein paar Monaten eben auch jeder SaaS-Anbieter, der etwas auf sich hält. TikTok für Ads. GitHub für Repos. Notion für Wissen. Stripe für Payments. Jira, Linear, Productive für Tickets. Salesforce, HubSpot, Pipedrive für CRM. Slack, Teams, Discord für Chat.
Das fühlt sich an wie 2015, als plötzlich jedes Tool eine Zapier-Integration hatte. Nur mit einem entscheidenden Unterschied: Damals war ein Zap eine deterministische Pipeline. Heute ist jeder MCP-Aufruf ein LLM-Token-Verbrauch, ein potenzielles Halluzinations-Risiko und eine neue Auth-Surface.
Warum das jetzt explodiert
Drei Dinge sind 2026 zusammengekommen:
- SaaS-Anbieter haben verstanden, dass „LLM-fähig" ein Verkaufsargument ist. Wer 2026 keinen MCP-Endpunkt anbietet, fliegt aus den Agent-Marketplaces. Das ist kein technischer Push mehr, das ist Marketing.
- Die großen Cloud-Anbieter haben MCP in ihre Plattformen eingebaut. Google Cloud Next 2026 hat „Agents are the architecture now" plakatiert. AWS hat AgentCore mit nativer MCP-Gateway-Unterstützung gelauncht. Azure folgt. Damit wird MCP von einem Anthropic-Hobby zu Infrastruktur.
- Die Modelle werden tool-hungriger. Ein moderner Agent ruft pro Task nicht mehr eine API auf, sondern fünf bis fünfzehn. Multipliziere das mit zwanzig angeschlossenen Tools, und du hast schnell vier- bis fünfstellige API-Calls pro Mitarbeiter und Tag.
Was MCP-Sprawl konkret heißt
In einem typischen Mittelständler-Stack sehen wir 2026 das hier:
- Ein MCP-Server pro Ticket-System (Jira, Linear oder Productive)
- Einer für Git-Hosting (GitHub, GitLab)
- Einer für Wissen (Notion, Confluence)
- Einer pro CRM (HubSpot, Salesforce)
- Einer für Buchhaltung (Lexware, DATEV, sevDesk)
- Einer für Cloud (AWS, Azure, Hetzner, Forge)
- Einer pro Marketing-Tool (Ads, Analytics, Mail)
- Einer pro internem System (ERP, Warenwirtschaft, Helpdesk)
Realistisch landest du bei 15 bis 25 Connectoren — und das ohne irgendetwas „Exotisches". Jeder Connector hat sein eigenes Auth-Modell (OAuth, API-Key, Service-Account, Personal-Access-Token), seine eigene Rate-Limit-Logik, seine eigene Telemetrie und seine eigenen Token-Kosten pro Call. Eine zentrale Übersicht hat niemand.
Die drei Probleme, die niemand bespricht
1. Token-Kosten skalieren stiller, als du denkst
Jeder MCP-Server liefert seine Tool-Definitionen als JSON-Schema in den Kontext des Modells. Ein einzelner Endpoint braucht oft 500 bis 2000 Input-Tokens, nur um „verfügbar" zu sein. Bei zwanzig Servern sind das schnell 30.000 Tokens pro Konversationsstart — bevor der Agent irgendetwas getan hat. Das frisst Kontextfenster, kostet pro Call Geld und macht die Modelle langsamer.
Wir sehen bei Kunden ohne sauberes Tool-Routing eine Vervierfachung der Token-Kosten innerhalb von acht Wochen nach MCP-Adoption. Niemand weiß, woher das kommt, weil die Telemetrie der einzelnen Server nicht zentral läuft.
2. Auth-Sprawl ist Compliance-Russisches-Roulette
Zwanzig Connectoren heißen zwanzig Geheimnisse. Wenn ein Entwickler MCP-Server ausprobiert, landet der GitHub-Token im klartext in einer Config-Datei, der Productive-Token in einer Environment-Variable auf seinem Laptop, der HubSpot-OAuth-Refresh-Token in einem Browser-Profil. Niemand weiß, welcher Token welche Scopes hat, niemand kann rotieren, niemand kann revozieren.
Im Schadensfall — und der wird kommen — hast du keine Antwort auf die einzige Frage, die zählt: „Welche Daten konnten von welchem Agenten in welchem Zeitraum gesehen werden?"
3. Beobachtbarkeit endet an der Server-Grenze
Jeder MCP-Server loggt für sich. GitHub loggt deine Git-Calls, Productive loggt deine Task-Calls, Notion loggt deine Page-Calls. Was niemand loggt: die Kette. Welcher Agent hat welchen Server in welcher Reihenfolge aufgerufen, mit welcher Begründung, im Auftrag welches Benutzers? Genau das brauchst du aber, sobald ein Agent etwas Falsches getan hat. Und der wird etwas Falsches tun.
Wie wir das bei unseren Kunden angehen
Seit ein paar Monaten bauen wir eine Architektur, die genau diese drei Probleme adressiert — und die wir mittlerweile bei mehreren Kunden produktiv haben. Drei Bauteile, die wir für 2026 als Pflicht sehen:
Ein zentrales Agent-Gateway
Statt dass jeder Agent direkt mit jedem MCP-Server spricht, gibt es genau einen Endpunkt: unser Agent-Gateway. Es spricht selbst MCP nach oben (zu den Agenten) und routet nach unten zu den jeweiligen Servern. Damit haben wir einen Ort, an dem wir Tool-Definitionen filtern, Aufrufe protokollieren und Policies durchsetzen können. Token-Verbrauch der Tool-Schemas geht runter, weil wir pro Agent-Sitzung nur die wirklich relevanten Tools laden.
Ein zentraler Token-Vault
Keine Geheimnisse in Configs, keine in Environment-Variablen, keine auf Entwicklerlaptops. Stattdessen ein Token-Vault, der pro Verbindung kurzlebige Credentials ausgibt. Der Agent bekommt nie den echten GitHub-PAT zu sehen — er bekommt einen Vault-Reference. Rotation, Revocation und Audit-Log laufen zentral. Im Schadensfall können wir tatsächlich beantworten, was passiert ist.
Eine Policy-Engine, die mehr kann als „on/off"
Die meisten MCP-Server haben binäre Zugriffsmodelle: entweder hat dein Token Zugriff oder nicht. Das reicht 2026 nicht mehr. Wir nutzen eine fein-granulare Policy-Engine, die Aussagen formulieren kann wie „Agent X darf in Projekt Y read-only Tickets ziehen, aber keine Kommentare schreiben" oder „dieser Agent darf nur zwischen 8 und 18 Uhr Repos lesen, und nur die mit Tag ‚public'". Das klingt overengineered — bis du den ersten Vorfall hast.
Tracing über alle Hops hinweg
Jeder Agent-Call, jeder Tool-Call, jeder Sub-Aufruf landet in einem einzigen Tracing-System. Mit Cost-Attribution pro Aktion, Token-Verbrauch pro Schritt, Latenz pro Hop. Damit sehen wir nicht nur, dass ein Agent teuer ist — wir sehen, an welcher Stelle in welcher Pipeline er teuer wird. Das ist der Unterschied zwischen „wir geben jetzt 12.000 Euro im Monat aus" und „wir geben jetzt 12.000 Euro im Monat aus, weil dieser eine Triage-Agent jeden Ticket zweimal durch das CRM jagt".
Was Mittelständler jetzt tun sollten
Drei pragmatische Schritte, bevor MCP-Sprawl bei dir Realität wird:
- Inventarisieren, bevor es zu spät ist. Welche Tools sind heute schon MCP-fähig oder werden es in den nächsten drei Monaten? Welche Teams würden sie nutzen? Wer hält die Credentials? Das ist eine Stunde Arbeit für die meisten Mittelständler — und es ist die einzige Stunde, die du dir nicht sparen kannst.
- Eine Gateway-Entscheidung treffen, nicht zwanzig Connector-Entscheidungen. Statt jedem Team zu erlauben, „mal eben" einen MCP-Server zu integrieren, einigt euch auf einen Architektur-Standard: Alle Agenten gehen durch einen Gateway. Das ist eine Governance-Entscheidung, kein Tech-Stack.
- Token-Telemetrie ist Pflicht, nicht Optional. Wenn du nicht messen kannst, wie viel jeder Agent für jeden Tool-Call ausgibt, fliegst du blind. Egal welches Tracing-Tool — Hauptsache eines.
Fazit
MCP ist eine gute Idee. Der Standard ist sauber, die Adoption stark, das Ökosystem wächst. Aber jede gute Idee, die in zwölf Monaten von „neu" zu „überall" springt, produziert ein Sprawl-Problem. Und Sprawl-Probleme löst man nicht durch noch mehr Connectoren, sondern durch Architektur.
Wer 2026 die nächsten zwanzig MCP-Server einfach „dazusteckt", baut sich eine Wartungslast, die ihn 2027 einholt. Wer früh die Gateway-, Vault- und Policy-Frage stellt, hat in einem Jahr einen Vorsprung, der schwer einzuholen ist.
Wir sehen das gerade live. Und wir reden ehrlich darüber, weil sonst niemand es tut.
