Die Capability-Schicht: Tausende und Abertausende Connectoren und das Ende der Custom-Integrationen

Zwanzig Jahre lang war die Einheit der Integrationsarbeit der Endpoint. Man hatte eine URL, ein Verb, ein Wire-Format, eine Ratenbegrenzung, einen OAuth-Fluss, und man schrieb Klebstoffcode, um das Ganze zusammenzuhalten. Die Einheit verändert sich. Sie ist die Capability: genau eine Sache, die ein Agent an einem System tun kann. «Die Rechnung senden» ist eine Capability. «Die letzte Bestellung stornieren» ist eine Capability. «Die offenen Tickets ziehen» ist eine Capability. Der Endpoint ist ein Implementierungsdetail darunter.

Deshalb liefert Vinkius einen Katalog von Capabilities, und keinen Katalog von API-Wrapper. Heute hält der Katalog Tausende und Abertausende verwaltete Connectoren und 61.738 Capabilities, und die Zahl, die zählt, ist nicht die Anzahl der Connectoren. Es ist, dass jede Capability eine Einheit ist, die man hosten, versionieren, authorisieren, messen und auditieren kann, so wie man jeden anderen Service im Stack auditieren würde.

Dieser Artikel ist eine Anatomie dieser Schicht. Was eine Capability tatsächlich ist, wie ein Request sie durchläuft, auf welche fünf Wege eine Capability geliefert wird, und die Planenmathematik und das Sicherheitsmodell darunter. Keine Marketingmathematik: jede Zahl hier ist, was das Produkt liefert.

Der Name ist kein Zufall. Im Produkt sucht man nicht nach Connectoren, man sucht nach «AI Capabilities». Der Katalog, die Suchleiste und das Upgrade-Pitch sprechen dieselbe Einheit. Wenn ein Vendor eine Schicht der Agenten-Ära verkauft, sagt die Verkaufseinheit, was er glaubt zu verkaufen. Vinkius verkauft Aktionen, nicht Endpoints.

Die Arbeitseinheit ist nicht mehr der Endpoint

Ein Agent sendet keinen HTTP-Request an einen Dienst. Er sendet Absicht. Im Ausführungsmodell von Vinkius hat die Absicht genau drei Felder. Die Capability, die die Aktion ist, die zu erledigen ist. Der Input, die Daten, die die Aktion braucht. Und die Identität, die der Benutzer ist, der die Aktion autorisiert. Alles andere, Authentifizierung, Berechtigungen, die Zuordnung auf die richtige Operation, der Retry nach einem transienten Fehler, gehört zur Plattform, nicht zum Agenten.

Dann laufen vier Stufen. Authenticate verbindet das richtige Benutzerkonto. Authorize erzwingt die Berechtigungen der gewünschten Aktion. Resolve mappt die Capability auf die korrekte Systemoperation. Execute führt die Operation aus, macht den Retry, wenn er geboten ist, und verbucht, was passiert ist. Das Ergebnis kommt strukturiert zurück: ein Status, eine normalisierte Ausgabe, und eine Spur.

Achten Sie darauf, was das Modell nie sieht. Das Wire-Protokoll. Die Retry-Strategie. den Berechtigungscheck. Es bat um ein Ergebnis und bekam eines.

Dort steckt der größte Teil der Branche immer noch fest. Modelle sind besser, ein Ergebnis zu nehmen und darüber nachzudenken, als einen Fetch-Call zu hüten. Die Capability-Schicht ist der Ort, an dem Absicht aufhört, ein Prompt zu sein, und eine Transaktion wird.

Ein weiteres Stück der Anatomie ist wichtig, wenn man Flotten von Agenten betreibt: Wer handelt? Jeder Capability-Aufruf trägt eine Identität, und die Identität ist ein Benutzer, nicht das Modell. Das Produkt ist um diese Tatsache gebaut. Man kann eine Anwendung für eine unbegrenzte Zahl von Endbenutzern bauen, und die Verbindungen und Zugangsdaten jedes Benutzers bleiben vollständig isoliert von allen anderen und von der Plattform selbst. Der Agent ist die Hand. Die Identität ist, wem die Hand gehört.

Was der Katalog liefert

Zuerst die Zahlen, denn sie verankern alles. Tausende und Abertausende Connectoren. 61.738 Capabilities. Die meisten Connectoren sind offiziell, veröffentlicht und von Vinkius gewartet, und der Rest stammt aus der Community. Eine wachsende Zahl von Einträgen trägt das «Neu»-Zeichen. Der Zähler der Website wird aus den Katalogdaten generiert, und er ist keine Marketingkonstante, die jemand jedes Quartal neu tippt; genau das ist der Unterschied zwischen einer Zahl, die man einem Board vorlegen kann, und einer, die nur schmeichelt.

Noten gehören zur Oberfläche. Die offiziellen Connectoren tragen ein A+, und die Community-Einträge tragen Buchstabengraden, die bis hinunter zu F reichen, also ist der Beurteiler keine Dekoration. Ich habe Vendors zusehen, Qualitätsnoten zu veröffentlichen, die niemand reproduzieren kann. Unsere liegen in den Katalogdaten neben jedem Eintrag, und dort will man sie.

Veröffentlichen ist die andere Seite des Hauptbuchs. Die offiziellen Einträge werden von Vinkius gewartet, und die Community-Einträge von ihren Publishern. Die Unterscheidung zählt aus einem Grund. Offiziell heißt, dass Vinkius haucht. Bei einem Community-Eintrag haftet der Publisher. Beide durchlaufen dieselbe Prüfungsleiste und landen in derselben Suche, und das Vertrauensbadge ist eine Haftungs-Marke, keine Kategorie.

Was «verwaltet» wirklich bedeutet, ist der öde Teil. Vinkius hostet den Connector, wartet ihn, aktualisiert ihn und betreibt die Authentifizierung. Wenn OpenAI oder Salesforce einen Endpoint ändert, ist das unser Job, nicht Ihrer. Jeder Connector im Katalog landet als verifizierte Oberfläche: produktionsreif, mit den Garantien, die das Label mitbringt. Der Control Plane sagt es in einer Zeile, MCP VERIFIED, PRODUCTION READY, VINKIUS GUARANTEED, und ein Klick aktiviert den Connector in Ihrem Account.

Den Connector eines anderen zu hosten, bedeutet, die Haftung zu übernehmen. Wenn ein Dritter ein Tool stilllegt, landet die Korrektur im Connector, nicht in Ihrer Anwendung. Der Katalog ist der Ort, an dem diese Haftung liegt, und wo Ihre Wartungsrechnung aufhört.

Die Breite zeigt sich in der Namensliste. OpenAI, Anthropic, Stripe, GitHub, Slack, Salesforce, Tesla, PayPal, Plaid, Datadog, Jira, Shopify, dazu die lange Schwänze: Idealista, Semrush, ElevenLabs, Hugging Face. Die Katalogseite reduziert das Ganze auf einen Satz. Eine Verbindung, jedes Werkzeug, das Ihr Agent aufrufen kann.

Zwei Wege, zu stöbern

Es gibt zwei Regale, und sie beantworten verschiedene Fragen. Das erste ist redaktionell: zwölf handkurate Kategorien, Industry Titans, Superpower, Loved by Developers, AI Frontier, The Unthinkable, Money Moves, Ship It, Talk to Me, Growth Engine, Brain Trust, Fort Knox, und Friends of MCP. Das sind Geschmackssachen. Das ist die Antwort auf «Zeig mir, was meine Zeit wert ist».

Die zweite ist organisch: zweiundzwanzig Kategorien, die automatisch aus den Manifesten befüllt werden, von Productivity und Developer Tools bis zu Nischen-Vertikalen wie Legal, Healthcare, Travel and Hospitality, und Real Estate. Das ist die Antwort auf «Was kann ich für dieses Team gleich jetzt anstöpseln».

Im Produkt muss man kein Regal wählen. Discovery, Explore, Favorites, Activated, und Library stehen nebeneinander, und die Katalogsuche ist dieselbe Suche, die ein Agent benutzt, wenn er mitten in einer Aufgabe nach einem Werkzeug sucht. In Explore tun vier Tabs die Arbeit: Top Curated, Newest, Top Tags, und Top Categories. Jeder ist eine andere Antwort auf dieselbe Frage, welche von den Tausenden und Abertausenden die eigene ist.

Die Regale sind auch eine Ansage. Ein Katalog, der zwölf Geschmacksschubladen baut, behandelt die Auswahl als eigene Leistung. Wer nur eine sortierte Liste anbietet, delegiert die Auswahl an den Suchenden. Die zwölf Redaktionsregale sind die Redaktion, und die Redaktion ist der Teil, den kein Suchfenster ersetzt. Der Katalog lässt sich auch ohne Account durchblättern. Discovery, Tags, Kategorien und Neuheiten sind öffentlich, denn der Katalog ist eine Entdeckungsfläche, und Entdeckung sollte nicht hinter einer Anmelde-Mauer sitzen. Die Aktivierung ist der Ort, an dem der Account zählt. Ein Klick, und der Connector ist in Ihrem Control Plane am Leben. Die Suche arbeitet an der Aufgabe, nicht nur am Namen: man beschreibt, was man braucht, und der Katalog findet die Capabilities, die sie antreiben.

Die fünf Wege, auf denen eine Capability ankommt

Eine Capability ist ein Vertrag über dem Transport. Darunter liefert einer von fünf Server-Typen sie aus.

Der API-Server ist das Arbeitstier. Er ist ein REST-Proxy: man zeigt ihn auf eine Basis-URL, und die Oberfläche macht jede API in eine MCP-Schnittstelle um, ohne dass man die Client-Seite neu baut. Liefert der Vendor eine Spec, importiert man sie, und der Capability-Satz erscheint.

Der Agent-Skills-Server ist absichtlich anders. Er gibt Skill-Dateien frei, die das Modell bei Bedarf liest, in einem Muster namens progressive Offenlegung: das Modell sieht, was da ist, und zieht die Details nur, wenn es diesen Weg wählt. Das ist die Form der Capability, die zu Codebasen und Wissensbeständen passt, in denen die vollständige Tool-Beschreibung nicht in den Kontext würde.

Der MCP-Server-Deploy-Server ist Ihr eigener Code. Man packt ihn, schickt ihn an die Edge, und er läuft in der V8-Isolate-Laufzeitumgebung, über die ich im Detail hier geschrieben habe. Die Laufzeitumgebung ist der Ort, an dem die Zahlen für Kosten und Latenz wohnen.

Der YAML-Server ist der deklarative. Ein Manifest in YAML, zur Deploy-Zeit kompiliert. Das ist die Form der Capability, die Teams in Git wollen, geprüft wie Infrastruktur.

Authentifizierung läuft unter all dem in vier Formen. Keine, wenn die Oberfläche öffentlich ist. Bearer, für tokenbasierte Dienste. Basic, für die Legacy-Ecke. Und ein eigener Header, für die Vendors, die sich weigern, in eines der anderen drei zu passen. Der Punkt der Taxonomie ist, dass das Modell nichts davon sieht. Das Modell sieht eine Capability; der Transport, die Auth-Form und die Retry-Strategie sind das Problem der Plattform.

Von der Nutzerseite ist Authentifizierung keine Mauer. Jeder Connector zeigt seinen Zustand auf den ersten Blick: Einrichtung erforderlich, verbunden, bereit. Keine versteckte Login-Seite, kein «Es sollte doch funktionieren». Es gibt noch eine Einheit, die ihren Namen verdient, bevor die Planenmathematik kommt: der Capability-Satz. Jeder Connector liefert seinen vollständigen Satz, die exakten Aktionen, die die KI wählen kann, wenn man sie mit diesem Connector arbeiten lässt. Der Agent sieht nicht den ganzen Katalog auf einmal; er sieht die Tools, die er tatsächlich hat. Das ist kein Produkt-Detail. Das ist, wie der Katalog den Kontext des Modells ehrlich hält.

Die Planenmathematik

Capability-Zugang ist an genau einer Stelle an den Plan gekoppelt: die Free-Tier. Sie fährt hundert Requests pro 30-Tage-Zyklus, einen Verbindungstoken, zwei Kataloginstallationen, und ihre Dashboards sind mit Beispieldaten beschriftet, damit niemand eine Demo mit einem lebenden System verwechselt. Von den Paid-Tiers aufwärts gibt es im Katalog keine Installations-Obergrenze, und die Request-Obergrenzen sind die echten Planungszahlen: 5.000 pro Zyklus bei Lite, 25.000 bei Starter, 100.000 bei Pro, und 500.000 bei Business.

Die Obergrenzen sind keine Dekoration. Sie sind die Messschicht. Und sie sind ein Planungsinstrument: Wer seine Obergrenze kennt, kann Kostenplan und Ausführungsgrenze auf dieselbe Zahl legen. Wer sie nicht kennt, verliert die Kontrolle über die Ausgaben, bevor er sie sieht. Eine Capability, die eine Bestellung stornieren kann, kann auch in einer Schleife laufen, und eine Schleife, die nachts tausend Dollar verrennt, ist ein Governance-Problem, bevor es ein Ingenieur-Problem ist. Die eigene KPI des Produkts, Cost Saved, misst die Bytes, die ein Kostenlimit aus dem Ausgangspfad streicht, also ist die Zahl auf dem Dashboard eine Zahl, die man in einer Budget-Ronde verteidigen kann.

Über der Obergrenze wird das Überlaufkontingent mit weicher Grenze abgerechnet, ohne den Aufruf abrupt abzubrechen, und das ist gewollt. Ein harter Stopp in Produktion ist eine Warteschlange. Abgerechneter Überlauf ist ein Posten in der Rechnung. Das ist die ganze Philosophie der Obergrenzen: sie sind Zahlen, gegen die man plant, nicht Wände, an die man stößt.

Verbindungstokens steigen die Leiter: drei bei Lite und Starter, zehn bei Pro, fünfundzwanzig bei Business. Die Aktivitätshistorie läuft von drei Tagen bei den Einstiegs-Paid-Tiers auf sieben bei Pro und dreißig bei Business, und die Audit-Trail der obersten Stufe ist die unveränderliche. Dort wohnen Organisationen: Teams, Rollen, Projekt-Bereiche, Service Accounts und API-Schlüssel-Provisionierung, SSO, eine 30-tägige unveränderliche Audit-Trail, sofortige Token-Widerrufung, und ein Notstopp mit Schutzschalter.

Die Sicherheitsschicht, nach der Ihr CISO fragt

Jeder Connector läuft in seiner eigenen versiegelten Sandbox. Mindestens vierunddreißig Regeln werden bei jedem Request erzwungen, und sie decken Speicherlimits, CPU-Limits, SSRF-Schutz, Blockierung privater Netzwerke, Schutz vor bösartigen Dateien, und Isolierung von Zugangsdaten. Die Regeln sind kein Zierat. Sie sind die Liste, die Sie einem Prüfer vorlegen, wenn er fragt, was zwischen Ihrem Agenten und dem fremden System liegt. Die Antwort steht dort, und sie ist prüfbar. Sicherheitsereignisse laufen in Echtzeit in Datadog, Splunk, oder einen Webhook. Die Audit-Trail ist signiert und verkettet, Ed25519-Signaturen über SHA-256-Blöcke, also kann eine gefälschte Aufzeichnung nicht leise verschwinden, ohne die Kette zu brechen.

Zugangsdaten folgen einer Regel. Im Umfang, nutzerseitig kontrolliert, jederzeit widerrufbar, und die Plattform lernt niemals auf Ihren Daten. Die eigene FAQ des Produkts sagt die zweite Hälfte laut, damit man sie zitieren kann: «Vinkius lernt niemals auf Ihren Daten, und Sie können den Zugriff jederzeit widerrufen.» Endbenutzer-Zugangsdaten werden sicher abgelegt und nach dem Speichern nie wieder angezeigt, und die Verbindungen jedes Benutzers bleiben vollständig isoliert von allen anderen und von der Plattform. Die Deploy-Audit-Oberfläche exportiert ein PDF, und das ist das Format, das ein Regulator oder ein Vorstandsausschuss tatsächlich liest.

Seit Jahren fordere ich Vendors auf, diese zwei Sätze auf ihrer Seite zu schreiben. Der Katalog schreibt sie.

Warum verwaltet gegen selbst gelötet gewinnt

Jede Custom-Integration ist ein Versprechen, das man für immer halten muss. Der Vendor ändert ein Feld. Man schreibt den Parser neu. Der Auth-Fluss rückt. Man jagt ihm hinterher. Eine Integration, die niemand seit einem Jahr gesehen hat, ist eine Schuld, die sich als Feature verkleidet. Der Katalog dreht das Wartungsmodell um. Hosting, Authentifizierung, Ausführung, Monitoring, Aktualisierungen: die Plattform tut sie, und eine Capability wird zu einer Zeile in einem Manifest, statt zu einer Klebstoff-Code-Basis, die jemand hüten muss.

Die Mathematik dieser Umkehrung ist das Argument. Nehmen wir an, Ihr Stack braucht hundert Connectors. Hundert Custom-Integrationen sind hundert Wartungsversprechen, jedes ein Parser, der faulen kann, ein Auth-Fluss, der brechen kann, eine Version, die einem unter den Füßen wechselt. Hundert Katalog-Connectors sind hundert gewartete Oberflächen, und die Wartungskosten liegen auf der Plattform-Seite der Rechnung. Das ist der Unterschied zwischen einem Werkzeug kaufen und es besitzen.

Es gibt auch das Argument vom ersten Tag. Ihre KI-Anwendung startet mit Tausenden von Connectors im Katalog, und das ist ein echter Unterschied zum Team, das sein erstes Quartal damit verbringt, die zwei Integrationen der Demo zu verdrahten. Der Katalog ist der Grund, warum der erste Commit einer Agent-Anwendung der produktive sein darf.

Von der Client-Seite ist es dieselbe Form. Die Oberflächen des Katalogs sprechen MCP, was heißt, dass derselbe Connector bei ChatGPT, Claude und Gemini, bei Cursor, Cline und VS Code, und über den Vercel AI SDK in Ihrer eigenen Anwendung funktioniert. Sie warten den Capability-Satz einmal, und jeder Client, der das Protokoll spricht, kann ihn aufrufen.

Wo das hineinpasst

Der Katalog ist die Capability-Schicht. Der Control Plane sind die Regeln der Aufrufe: Identität, Erzwingung auf dem Weg, gedeckelte Ausgaben, Geheimnis-Isolierung, ein fälschungssicheres Ledger, Trace-Kontinuität, ein menschliches Tor und ein Off-Switch, und ein gemessener Overhead. Die acht Regeln habe ich im Control-Plane-Artikel geschrieben. Die V8-Isolate-Laufzeitumgebung hat einen eigenen Artikel. Der Katalog ist der Ort, an dem diese Regeln etwas haben, was sie regieren.

Drei Artikel, ein Stack. Der Control-Plane-Artikel deckt die Regeln der Aufrufe. Der V8-Artikel deckt, wo der Code läuft. Dieser deckt die Einheit, die die anderen zwei brauchbar macht. Ohne Katalog regiert der Control Plane nichts, und die Isolate-Laufzeitumgebung hat nichts zum Laufen. Der Katalog entscheidet, was möglich ist. Die Regeln entscheiden, was erlaubt ist. Die Laufzeit entscheidet, was es kostet. Zusammen sind das die ganze Agenten-Infrastruktur, und jede der drei Schichten hat ihren eigenen Artikel. Der Katalog ist die Angebotsseite der Agenten-Ökonomie. Er entscheidet, welche Aktionen existieren, wer sie wartet, was sie kosten, und was passiert, wenn sie scheitern.

Wenn ein Agent nach der Welt fragt, ist die Capability-Schicht die Tür, und der Control Plane der Riegel. Die Aufgabe des Katalogs ist, die Tür breit genug zu machen, damit kein Agent je selbst eine bauen muss. Die Messlatte, die ich vom Katalog, und von jedem Katalog, der denselben Raum beansprucht, verlangen werde: verifizierte Oberflächen, Noten, die man nachrechnen kann, eine Messung, die ein Finanzteam verteidigen kann, und eine Audit-Trail, die man nicht stillschweigend editieren kann. Alles andere ist ein Verzeichnis, keine Schicht.