Ein MCP-Endpunkt für Claude: alle Tools auf einmal verbinden

Die kurze Antwort: Statt Claude zehn MCP-Server einzeln hinzuzufügen, fügst du einen einzigen Gateway-Endpunkt hinzu. Claude behandelt ihn wie jeden Remote-MCP-Server (eine URL, eine OAuth-Zustimmung), und hinter dieser Verbindung sitzen alle deine Tools, namespaced in einem Katalog, der sich selbst aktualisiert, wenn sich deine Verbindungen ändern. Aus zehn Setups wird eins, auf jeder Maschine und Oberfläche, auf der du Claude nutzt.

Das ist der client-spezifische Rundgang zu einem Muster, das wir allgemein in Was ist ein MCP Gateway? behandeln. Ehrlichkeit zuerst: Wir verkaufen kein Gateway, dieser Guide empfiehlt also keinen Anbieter; das Muster funktioniert gleich mit jedem Gateway, das einen Remote-MCP-Endpunkt anbietet. Was wir bauen, ist Tulimoa Memory, ein Memory-Server, der neben einem Gateway läuft, und ein Abschnitt weiter unten zeigt, wie du ihn dazunimmst.

Die zwei Wege, wie Claude sich mit Tools verbindet

Der Default-Weg: ein Eintrag pro MCP-Server. In Claude Code ein claude mcp add pro Server; in Claudes App-Einstellungen ein Connector pro Tool. Jeder Eintrag bringt seinen eigenen Auth-Flow, und jede Maschine oder Oberfläche wiederholt die Liste. Drei Server: okay. Zehn Server über Laptop, Desktop und Web-App: dreißig Einträge, die still auseinanderdriften. Und jeder weitere Server legt seinen Tool-Katalog in den Kontext, nachgerechnet in Wie viele MCP-Server sind zu viele?.

Der Gateway-Weg: ein Eintrag, insgesamt. Ein Gateway-Endpunkt ist aus Claudes Sicht selbst ein Remote-MCP-Server (diese Gleichheit ist der ganze Trick, erklärt in MCP Gateway vs. MCP-Server), Claude braucht also keinen Sonder-Support. Du fügst eine URL hinzu, bestätigst eine OAuth-Zustimmung, und der verschmolzene Katalog des Gateways erscheint: github__create_issue, crm__search_contacts, docs__search_pages, nebeneinander.

Wie das Verbinden aussieht

In Claude Code: ein Befehl mit der URL des Gateways als Remote-HTTP-Server, zum Beispiel: claude mcp add --transport http gateway https://your-gateway.example.com/mcp, mit der URL aus der Doku deines Gateways. Die erste Session löst den OAuth-Login aus (manche Gateways nutzen stattdessen einen API-Key-Header), danach steht die volle namespaced Tool-Liste in jedem Projekt bereit.

In Claudes Apps (Web und Desktop): dieselbe URL als Custom Connector in den Einstellungen hinzufügen, Zustimmungsbildschirm bestätigen, fertig. Gleicher Katalog, kein Terminal beteiligt; wenn Einstellungsmenüs eher deins sind als CLIs, führt der Beitrag für Nicht-Entwickler diesen Weg im Detail.

Weil jede Oberfläche auf denselben Endpunkt zeigt, hört die lästige Frage "welche Maschine hat welche Tools" auf zu existieren. Du hast das Gateway einmal konfiguriert; Claude sieht überall das Ergebnis.

Was sich konkret verbessert

Eine Zustimmung statt zehn Auth-Flows. Die einzelnen Tool-Logins passieren einmal, am Gateway, wo das Gateway die Zugangsdaten verwahrt. Claude selbst hält eine einzige Verbindung. Ein Tool rotieren oder widerrufen passiert zentral und berührt deine Claude-Konfiguration nie.

Eine Tool-Liste, die sich selbst aktualisiert. Verbinde mittags im Gateway-Dashboard ein neues Tool; deine Nachmittags-Session in Claude hat es einfach. MCPs List-changed-Mechanismus heißt, der Katalog erneuert sich, ohne dass du etwas editierst. Trenn ein Tool, und es verschwindet überall gleichzeitig.

Weniger Katalog-Aufblähung, eine Stelle zum Steuern. Zehn direkte Server kippen zehn volle Schema-Kataloge in jede Session. Ein Gateway ist der eine Punkt, an dem steuerbar ist, was lädt, die strukturelle Antwort auf die Context Tax.

Was ein Gateway nicht verbessert: Memory. Ein Gateway routet Tool-Aufrufe; es behält nicht, was Claude gelernt hat. Die Entscheidung aus der Session vom Montag ist am Donnerstag weg, wenn sie nichts speichert. Das ist eine eigene Schicht, und um die geht es im nächsten Abschnitt.

Memory neben das Gateway stellen

Memory muss nicht im Gateway leben. Ein Memory-Server ist einfach ein weiterer Remote-MCP-Server, neben dem Gateway-Eintrag hinzugefügt, und Claude sieht seine Tools neben dem Katalog des Gateways.

Volle Transparenz: Genau das bauen wir. Tulimoa Memory ist ein eigener MCP-Server; er bündelt deine Tools nicht und ist kein Gateway. Er speichert, was Claude lernt (Entscheidungen, IDs, Checkpoints), und verdichtet das einmal pro Nacht zu einem Wissensgraphen, sodass der Abruf in der nächsten Session nach Bedeutung funktioniert. In Claude Code ist das ein Befehl mehr: claude mcp add --transport http tulimoa-memory https://memory.tulimoa.com/mcp --header "Authorization: Bearer tlm_mem_...". Die Memory und ihren Schlüssel legst du im Dashboard an, mit kostenlosem Account und einmalig $1 Startguthaben; jeder Aufruf kostet $0,002, ohne Abo. Die Verbindungsanleitung deckt andere Clients ab.

Jeder Client, den du mit demselben Schlüssel verbindest, liest und schreibt dieselbe Memory, also ist die Entscheidung, die du am Montag gespeichert hast, am Donnerstag einen recall entfernt, egal welches Gateway daneben sitzt.

Noch kein Gateway gewählt? Unser öffentlicher Verzeichnis-Server braucht zum Lesen keinen Account: claude mcp add --transport http tulimoa https://mcp.tulimoa.com/mcp gibt Claude Live-Suche über das Verzeichnis für KI- und MCP-Software, das auch zeigt, welche deiner Tools einen MCP-Server mitbringen, und ist zugleich eine Zwei-Minuten-Demo, wie sich eine Remote-MCP-Verbindung in Claude anfühlt.

Ein praktischer Tipp, egal welchen Endpunkt du verbindest: Frag Claude danach "welche Tools hast du jetzt?". Die namespaced Liste einmal zu lesen lässt das ganze Denkmodell einrasten, und es ist zugleich der Check, dass die Verbindung steht.

Häufige Fragen

Unterstützt Claude MCP Gateways nativ?

Es braucht nichts Spezielles, und das ist der Punkt: Ein Gateway präsentiert sich als normaler Remote-MCP-Server, und die verbindet Claude in Claude Code (claude mcp add) und über Custom Connectors in den Apps. Wenn dein Claude einen Remote-MCP-Server hinzufügen kann, kann es ein Gateway nutzen.

Verliere ich mit einem Endpunkt die Granularität der Tool-Berechtigungen?

Nein. Claude zeigt und bestätigt weiter einzelne Tool-Aufrufe, und das Gateway ergänzt seine eigene Ebene: Scopes pro Verbindung, Widerruf und ein Audit-Trail jedes gerouteten Aufrufs. Du gewinnst einen zweiten Kontrollpunkt, statt einen zu verlieren.

Funktioniert das auch mit anderen MCP-Clients?

Ja, und das ist der halbe Reiz. Derselbe Endpunkt funktioniert in jedem MCP-sprechenden Client, sodass Claude, eine IDE und ein eigener Agent dieselben Tools sehen, und mit einem Memory-Server neben dem Gateway auch dieselbe Memory.