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?](/de/blog/what-is-an-mcp-gateway) behandeln. Ehrlichkeit zuerst: Tulimoa (unser Gateway) ist in früher Beta ohne öffentlichen Self-Serve-Signup, lies die Tulimoa-Details also als das, was Beta-Nutzer heute tun, und das Muster als das, was dir jeder Gateway-Endpunkt gibt.

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. Die Papierschnitte sind vertraut genug für einen eigenen Beitrag: [der Entwickler-Workflow](/de/blog/mcp-gateway-for-developers).

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](/de/blog/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, tulimoa__recall, 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://gateway.tulimoa.com/mcp. Die erste Session löst den OAuth-Login aus, 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, gleiche Memory, kein Terminal beteiligt; wenn Einstellungsmenüs eher deins sind als CLIs, führt [der Beitrag für Nicht-Entwickler](/de/blog/mcp-for-non-developers) 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 Zugangsdaten in einem verschlüsselten Vault liegen. 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](/de/blog/the-context-tax).

Memory, die dir zwischen Sessions folgt. Das ist spezifisch für ein Gateway mit Memory-Schicht: Dieselben remember-, recall- und checkpoint-Tools erscheinen in Claude Code und in den Claude-Apps, gestützt auf einen Speicher. Die Entscheidung, die du am Montag aus der Desktop-App gespeichert hast, ist am Donnerstag in Claude Code einen recall entfernt. Diese Kontinuität über Oberflächen hinweg gibt dir kein Client-eigenes Memory-Feature, und sie ist [der Teil, der aus unserer Sicht am meisten zählt](/de/blog/mcp-gateway-with-memory).

Das Muster heute ausprobieren, ohne Beta

Da unser Gateway noch nicht self-serve ist, hier die ehrliche Rampe. Tulimoas öffentlicher Verzeichnis-Server ist für alle live und braucht zum Lesen keinen Account: claude mcp add --transport http tulimoa https://mcp.tulimoa.com/mcp gibt Claude Live-Suche über das [Verzeichnis agent-fähiger Tools](/de/discover), was zugleich eine Zwei-Minuten-Demo ist, wie sich eine Remote-MCP-Verbindung in Claude anfühlt. Auf der [Gateway-Seite](/de/gateway) öffnet sich der Beta-Zugang, und alles in diesem Beitrag beschreibt, was Beta-Nutzer heute fahren.

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-Gateway, dieselbe Memory.