Warum MCP-Gateways allein das eigentliche Problem nicht lösen
KI-Agenten, die Produktionssysteme berühren, brauchen zwei Dinge.
Erstens brauchen sie eine sichere Ausführungsschicht: Authentifizierung, Autorisierung, Credential-Isolation, Audit-Logging, Output-Kontrollen und eine Runtime, die fail-closed reagiert, wenn etwas nicht stimmt.
Zweitens brauchen sie einen günstigen Weg, Backends bereitzustellen: nicht nur ein oder zwei handgebaute Integrationen, sondern Dutzende oder Hunderte echter Systeme, die zu nutzbaren Tools werden, ohne dass jede API zu einem eigenen kleinen Softwareprojekt wird.
Die meisten aktuellen MCP-Diskussionen drehen sich fast ausschließlich um das erste Problem.
Das ist nachvollziehbar. Das erste Problem ist beängstigend. Wenn ein Agent Produktions-Tools aufrufen kann, ist der Blast Radius real. Credentials lecken. PII rutscht durch. Audit-Trails gehen verloren. Ein halluzinierter Aufruf kann zu einem echten Incident werden.
Also ja, Gateways sind wichtig.
Sie sind die fehlende Control Plane zwischen dem Modell und den Systemen, auf die es ankommt.
Aber sie lösen das tiefere Skalierungsproblem nicht.
Dieses Problem sitzt eine Schicht früher.
Der eigentliche Engpass liegt nicht darin, wie wir Tool-Calls proxen.
Der eigentliche Engpass ist, dass das Erstellen von Backends nach wie vor viel zu teuer ist.
Deshalb lösen MCP-Gateways allein das eigentliche Problem nicht.
MCP hat das Interface-Problem gelöst
Abschnitt betitelt „MCP hat das Interface-Problem gelöst“MCP ist wichtig, weil es dem Ökosystem einen gemeinsamen Weg gibt, Tools zu entdecken und aufzurufen. Das ist bereits ein großer Schritt nach vorn. Es beseitigt unmittelbar eine ganze Klasse von Integrationsschmerzen: Clients und Hosts brauchen kein eigenes Protokoll mehr für jeden Tool-Anbieter.
Das ist echter Fortschritt.
Aber es ist nur ein Teil des Stacks.
Ein Protokollstandard ist nicht dasselbe wie ein skalierbares Integrationsmodell.
HTTP hat nicht die Notwendigkeit beseitigt, APIs zu entwerfen. OpenAPI hat nicht die Notwendigkeit beseitigt, Services zu bauen. Kubernetes hat nicht die Notwendigkeit beseitigt, gute Anwendungen zu schreiben.
Auf die gleiche Weise beseitigt MCP nicht die Arbeit, die nötig ist, um reale Systeme als nützliche, sichere und wartbare Tools verfügbar zu machen.
Es standardisiert die Invocation. Es macht Integrationen nicht günstig.
Diese Unterscheidung lässt sich in frühen Demos leicht übersehen, weil die ersten paar Tools immer die einfachsten sind. Ein simpler GitHub-Wrapper. Ein leichtgewichtiges Stripe-Beispiel. Ein interner Endpoint, der zum Proof of Concept wird.
Das reicht, damit das Protokoll wie die ganze Geschichte aussieht.
Das ist es nicht.
Der schwierige Teil beginnt, wenn sich die Frage ändert von „Können wir ein Tool bereitstellen?” zu „Können wir fünfzig Backends bereitstellen, ohne fünfzig kleine Softwareprodukte zu bauen?”
Gateways lösen Runtime-Kontrolle, nicht die Ökonomie der Integration
Abschnitt betitelt „Gateways lösen Runtime-Kontrolle, nicht die Ökonomie der Integration“Ein ernstzunehmender MCP-Einsatz braucht eine Runtime, die zwischen Agenten und Backends sitzt.
Diese Runtime sollte den Aufrufer verifizieren, Autorisierung durchsetzen, Credentials zur Laufzeit injizieren, jeden Aufruf protokollieren und Output-Kontrollen anwenden, bevor sensible Daten das Modell oder den Nutzer erreichen. Sie sollte fail-closed reagieren. Wenn eine Prüfung fehlschlägt, läuft nichts.
Genau dafür ist ein Gateway da.
Und genau hier passt ToolMesh hinein: eine selbst gehostete Ausführungsschicht zwischen Agenten und Infrastruktur, die Autorisierung, Secret-Injection, Audit-Logging und Output-Policies bei jedem Tool-Call durchsetzt. Diese Schicht ist nicht optional, wenn ein Agent Produktionssysteme berührt. Sie ist der Unterschied zwischen einer schicken Demo und einer Produktivarchitektur.
Aber ein Gateway regelt nur das, was bereits existiert.
Es kann Tool-Calls absichern. Es kann Policy zentralisieren. Es kann die Ausführung beobachtbar machen.
Was es allein nicht kann, ist die Kostenstruktur zu ändern, mit der die Tools überhaupt erst gebaut werden.
In diese Falle laufen viele Teams gerade hinein.
Sie verbessern die Control-Schicht und gehen davon aus, dass das Skalierungsproblem gelöst sei.
In Wirklichkeit haben sie den oberen Teil des Funnels abgesichert und den Engpass beim Erstellen unangetastet gelassen.
Das eigentliche N×M-Problem sitzt vorgelagert
Abschnitt betitelt „Das eigentliche N×M-Problem sitzt vorgelagert“Häufig wird das N×M-Problem in MCP als Kompatibilitätsproblem beschrieben: viele Clients, viele Backends, zu viele individuelle Paarungen.
MCP reduziert einen Teil davon, was gut ist.
Aber das schmerzhaftere N×M-Problem liegt vorgelagert.
Es liegt in der wiederholten Arbeit, die nötig ist, um Backend für Backend für Backend bereitzustellen.
Für jede API bauen Teams am Ende dasselbe Bündel an Themen immer wieder neu:
- Auth-Handling
- Parameter-Mapping
- Pagination
- Retries
- Error-Normalisierung
- Schema-Shaping
- Deployment-Packaging
- Runtime-Ownership
- Wartung, wenn sich die API ändert
Manchmal steckt diese Arbeit in einem eigenen MCP-Server. Manchmal wird sie zu einem dünnen Adapter. Manchmal wird sie als „kleine Integration” getarnt.
Aber es ist jedes Mal dasselbe Muster.
Deshalb fühlen sich wrapper-lastige Ansätze am Anfang gut an und im Maßstab fürchterlich.
Die erste Integration ist spannend. Die fünfte ist handhabbar. Die zwölfte wird zum Priorisierungsproblem. Bei der zwanzigsten fangen Teams an, nur noch die Endpoints freizugeben, die sie zwingend brauchen.
Alles andere landet im Backlog.
Das Ergebnis ist bekannt: eine Landschaft aus halben Wrappern, lückenhafter Abdeckung, dupliziertem Boilerplate, mehreren Runtimes und einem Long Tail von APIs, die Agenten nie zur Verfügung stehen.
Das ist kein Gateway-Versagen. Es ist ein Versagen beim Backend-Erstellen.
Bessere Proxies machen das Erstellen von Backends nicht trivial
Abschnitt betitelt „Bessere Proxies machen das Erstellen von Backends nicht trivial“Das ist der Kernpunkt.
Ein besserer Proxy kann Sicherheit, Konsistenz und Beobachtbarkeit verbessern.
Er kann nicht verhindern, dass ein Wrapper ein Wrapper bleibt.
Wenn jedes neue Backend immer noch mit „jemand muss einen eigenen MCP-Server bauen und betreiben” beginnt, ist die Ökonomie weiterhin kaputt.
Man kann ein wunderschön konstruiertes Gateway vor diese Welt setzen, und es wird die Produktionsreife absolut verbessern.
Aber das System wird trotzdem schlecht skalieren, weil die Arbeitseinheit weiterhin zu teuer ist.
Jedes zusätzliche Backend bedeutet immer noch mehr Code, mehr Packaging, mehr Deployment, mehr Ownership und mehr Oberfläche, die gewartet werden muss.
Die eigentliche Frage lautet also nicht:
„Wie setzen wir einen besseren Proxy vor MCP-Server?”
Die eigentliche Frage lautet:
„Wie machen wir das Bereitstellen eines Backends so günstig, dass der Long Tail nützlicher Systeme tatsächlich angebunden wird?”
Das ist der Punkt, an dem sich die Diskussion verlagern muss.
Dem MCP-Stack fehlt eine Description-Schicht
Abschnitt betitelt „Dem MCP-Stack fehlt eine Description-Schicht“Sobald man das Problem sauber trennt, wird die Architektur offensichtlich.
Die MCP-Ära braucht drei Schichten:
- eine Protokoll-Schicht für Discovery und Invocation
- eine Ausführungsschicht für Governance und Runtime-Kontrolle
- eine Description-Schicht, die Backends günstig bereitstellbar macht
Die erste Schicht ist MCP. Die zweite Schicht ist das Gateway. Die fehlende dritte Schicht ist dort, wo die meisten Ökosysteme noch unreif sind.
Ohne diese dritte Schicht bleibt jedes Backend eine eigene Engineering-Übung. Mit ihr wird das Bereitstellen von Backends zu einem deklarativen Problem.
Und das ändert alles.
Denn Descriptions skalieren anders als Code.
Eine gute Description-Schicht verschiebt wiederkehrende Logik aus maßgeschneiderten Wrappern in gemeinsames Runtime-Verhalten. Sie macht aus dem Bereitstellen eines Backends statt eines handgebauten Servers ein kompaktes, prüfbares, deklaratives Artefakt.
Das ist der architektonische Wandel, den das MCP-Ökosystem braucht, wenn es über eine Handvoll polierter Demos hinausgehen will.
DADL ist das fehlende Stück
Abschnitt betitelt „DADL ist das fehlende Stück“Genau hier kommt DADL ins Spiel.
DADL, die Dunkel API Description Language, geht einen anderen Weg als die wrapper-zuerst-Integration. Statt für jede REST-API einen eigenen MCP-Server zu schreiben, wird das Backend deklarativ in YAML beschrieben, während die Runtime die Standardmechanik übernimmt, die sonst immer wieder neu gebaut würde: Authentifizierung, Pagination, Retries und Error-Mapping.
Das ist nicht nur eine angenehmere Developer Experience. Es ist ein anderes Kostenmodell.
Ohne Description-Schicht ist die Standard-Arbeitseinheit: einen Server bauen. Mit einer Description-Schicht wird die Arbeitseinheit: das Backend beschreiben, es reviewen und die Runtime es sicher ausführen lassen.
Das ist eine radikal bessere Skalierungskurve.
Es bedeutet, dass Teams mehr von der echten API-Oberfläche bereitstellen können, statt nach einer engen „good enough”-Auswahl zu stoppen. Es bedeutet, dass sie nicht für jede Integration eine eigene Runtime, einen eigenen Dependency-Baum, ein Docker-Image und eine eigene Wartungslast brauchen. Es bedeutet, dass gemeinsame Integrationslogik dort lebt, wo sie hingehört: in einer gemeinsamen Ausführungsumgebung.
Und weil DADL bewusst kompakt und nahe an der Struktur bestehender API-Spezifikationen gehalten ist, öffnet es auch die Tür zu etwas noch Wichtigerem: moderne LLMs können aus einer vorhandenen API-Definition oft eine brauchbare erste Version generieren.
Hier ändert sich die Kategorie wirklich.
Denn sobald das Modell beim Generieren der Description helfen kann und die Runtime sie sicher ausführt, sinken die Kosten für das Anbinden eines neuen Backends um eine Größenordnung.
Genau so beginnt man, den Long Tail zu erschließen.
Warum das der OpenAPI-Moment für MCP ist
Abschnitt betitelt „Warum das der OpenAPI-Moment für MCP ist“Die beste Analogie hier ist nicht „noch ein Gateway” oder „noch ein Wrapper-Framework”.
Es ist OpenAPI.
OpenAPI hat HTTP nicht ersetzt. Es hat HTTP-Ökosysteme programmierbar gemacht. Es hat APIs auf eine Weise beschreibbar gemacht, die Tools, Docs, Code-Generatoren und Plattformen alle verstehen konnten.
Diese Verschiebung war nicht glamourös, aber sie hat die Ökonomie der API-Arbeit verändert.
Das MCP-Ökosystem braucht jetzt dieselbe Art von Verschiebung.
MCP standardisiert bereits, wie Tools aufgerufen werden. Was in vielen Architekturen noch fehlt, ist eine standardisierte Art, reale Backends zu beschreiben, sodass Tooling- und Runtime-Schichten die langweilige Arbeit einmal erledigen können, statt sie Teams für immer neu implementieren zu lassen.
Deshalb versteht man DADL am besten als OpenAPI für die MCP-Ära.
Nicht weil es MCP ersetzt. Nicht weil es ein Gateway ersetzt. Sondern weil es die fehlende Abstraktionsschicht zwischen rohen Backend-APIs und sicherer, steuerbarer Tool-Ausführung füllt.
Warum Entwickler sich dafür interessieren sollten
Abschnitt betitelt „Warum Entwickler sich dafür interessieren sollten“Für Entwickler geht es vor allem darum, der Integrationsmühsal zu entkommen.
Der meiste Wrapper-Code ist kein differenzierendes Engineering. Es ist repetitive Anpassungsarbeit, die Zeit verschlingt, die Wartungslast ausdehnt und mehr Runtime-Wildwuchs als Wert erzeugt.
Eine deklarative Backend-Schicht ändert das.
Statt zum zehnten Mal dieselbe Auth- und Pagination-Logik zu schreiben, können Teams sich auf das konzentrieren, worauf es wirklich ankommt: Domänenverhalten, Workflows, Guardrails und die Produktlogik, die auf diesen Tools aufbaut.
Ebenso wichtig: Niedrigere Integrationskosten erhöhen die API-Abdeckung.
Das ist sehr relevant.
Agenten-Systeme bleiben oft hinter ihrem Potenzial zurück, nicht weil das Modell schwach ist, sondern weil die verfügbare Tool-Oberfläche zu dünn ist. Das Backend unterstützt vielleicht fünfzig nützliche Operationen, aber nur sechs sind bereitgestellt, weil das Wrappen der übrigen zu teuer ist.
Wenn das Erstellen von Backends günstig wird, kann die Tool-Schicht beginnen, dem tatsächlichen System zu ähneln statt den Budget-Beschränkungen des Integrations-Teams.
Warum Architekten sich dafür interessieren sollten
Abschnitt betitelt „Warum Architekten sich dafür interessieren sollten“Für Architekten ist der Wert noch klarer.
Ein Drei-Schichten-Modell trennt Verantwortlichkeiten auf die richtige Weise.
MCP übernimmt die Kommunikation. Das Gateway übernimmt Trust, Kontrolle und Auditierbarkeit. Die Description-Schicht übernimmt die Backend-Skalierung.
Das bedeutet, dass Policy nicht mehr davon abhängt, wie ein bestimmter Wrapper geschrieben wurde. Credentials bleiben außerhalb des Modell-Kontextes. Audit wird konsistent. Sicherheit wird systemisch statt zufällig.
Und neue Integrationen lassen sich hinzufügen, ohne jedes Mal einen neuen Snowflake-Service zu schaffen.
Das ist die Art von Architektur, die Unternehmen tatsächlich wollen.
Nicht einen Zoo halb gewarteter MCP-Server. Nicht eine Zukunft, in der jedes neue Backend eine weitere Runtime bedeutet, die gepatcht und beobachtet werden muss.
Sie wollen eine stabile Ausführungsschicht und einen günstigen Weg, mehr Systeme unter diese Schicht zu bringen.
Genau deshalb reichen Gateways allein nicht aus.
Die Zukunft ist nicht Gateway gegen Description-Schicht
Abschnitt betitelt „Die Zukunft ist nicht Gateway gegen Description-Schicht“Sie ist Gateway plus Description-Schicht.
Das ist keine Entweder-oder-Wahl.
Man braucht MCP, weil das Ökosystem ein gemeinsames Protokoll braucht. Man braucht ein Gateway, weil Produktions-Tool-Calls Governance brauchen. Und man braucht eine Description-Schicht, weil sich keine Organisation leisten kann, das Bereitstellen von Backends über endlose handgebaute Wrapper zu skalieren.
Das ist der Stack.
MCP standardisiert die Invocation. ToolMesh sichert die Ausführung. DADL macht das Erstellen von Backends günstig genug, um zu skalieren.
Sobald man das Problem so sieht, fällt es leichter, das Marktrauschen zu ignorieren.
Die Gewinner in diesem Bereich werden nicht die Teams mit der hübschesten Proxy-Geschichte sein. Es werden die Teams sein, die beide Seiten der Gleichung lösen:
- sichere Ausführung für reale Systeme
- triviales Erstellen für reale Backends
Das eigentliche Problem
Abschnitt betitelt „Das eigentliche Problem“Also ja, baut das Gateway. Es wird gebraucht.
Aber verwechselt Runtime-Kontrolle nicht mit Integrations-Skalierung.
Das eigentliche Problem ist nicht, dass MCP bessere Proxies braucht. Das eigentliche Problem ist, dass das Ökosystem das Bereitstellen von Backends nach wie vor als individuelle Software-Arbeit behandelt, obwohl es eine deklarative Operation sein sollte.
Solange das so bleibt, wird der Long Tail nützlicher Systeme abgehängt bleiben, und Agenten-Infrastruktur wird immer wieder gegen dieselbe Decke stoßen.
Diese Decke bricht nicht, indem man härter proxt.
Sie bricht, wenn das Erstellen von Backends trivial wird.
Deshalb lösen MCP-Gateways allein das eigentliche Problem nicht.
Und deshalb ist DADL wichtig.
Nicht als Komfort-Feature. Nicht als Sidecar-Format. Sondern als die fehlende Description-Schicht, die sicheres Agenten-Tooling von handwerklicher Praxis in ein skalierbares System verwandelt.
In diesem Sinne ist der eigentliche Durchbruch nicht nur sicherere Tool-Calls.
Es ist, das Erstellen von Backends endlich günstig genug zu machen, damit die MCP-Ära skalieren kann.