Eine Komponenten-Bibliothek mit Claude verbinden

Es gibt den Eintrag im Verzeichnis, den Server von Hand und das Plugin. Alle drei führen zum selben MCP-Server, sie unterscheiden sich darin, wo die Verbindung gespeichert wird und wie viel neben den Werkzeugen noch mitkommt.

Der erste Weg ist der kürzeste. Anthropic führt ein Connector-Verzeichnis, und die Dokumentation beschreibt es als einen Katalog, der claude.ai, Desktop, Mobil, Cowork und Claude Code zugleich bedient. Ein Anbieter reicht seinen Server einmal ein, und wer ihn benutzen will, öffnet den Eintrag und klickt auf Verbinden. Es gibt keine Adresse zum Abtippen und keinen Schlüssel zum Kopieren.

Der zweite Weg ist der Server von Hand, in Claude Code über einen Befehl im Terminal. Der dritte ist das Plugin, und es ist der einzige der drei, der mehr liefert als eine Leitung: Neben dem Server stecken darin Fähigkeiten, Unteragenten, Hooks und eigene Befehle. Welcher Weg der richtige ist, hängt weniger vom Können ab als von der Frage, wo du mit Claude arbeitest.

Über das Verzeichnis, in einem Klick. Du öffnest den Eintrag des Anbieters, klickst auf Verbinden und meldest dich mit deinem Konto beim Anbieter an. Für Systra Tools liegt dieser Eintrag unter claude.ai/directory/systra-tools, und nach der Anmeldung bringt der Server den Umfang mit, der zu diesem Konto gehört, ohne dass irgendwo ein Schlüssel abgelegt wird.

Gibt es keinen Eintrag, legst du den Connector selbst an: unter Anpassen, Konnektoren, Benutzerdefinierten Konnektor hinzufügen, und dort die Adresse des Servers eintragen, bei Systra Tools systra.tools/api/mcp. Im Dialog wählst du, wie angemeldet wird. Sofort anmelden führt den Anbieter-Login gleich durch, bei Bedarf anmelden wartet, bis der Server danach fragt, und ohne Anmeldung ist für Server gedacht, die keinen Benutzer kennen. Ein fester Schlüssel lässt sich nur in diesem letzten Fall als Request Header hinterlegen, und diese Möglichkeit ist laut Dokumentation eine Beta, die nicht jede Organisation sieht.

Zwei Dinge sind dabei leicht zu übersehen. Auf einem Team- oder Enterprise-Plan legt eine Inhaberin den Connector für die Organisation an, und die Mitglieder verbinden sich danach mit ihrem eigenen Konto: Der Eintrag ist geteilt, die Anmeldung nicht. Und in der einzelnen Unterhaltung lässt sich jeder Connector über das Pluszeichen abschalten, was die häufigste Erklärung dafür ist, dass ein verbundener Server plötzlich nicht antwortet.

Es bringt die Gebrauchsanweisung mit. Ein MCP-Server liefert Werkzeuge, also etwa eine Suche und das Ausliefern von Quelltext. Ein Plugin in Claude Code bündelt daneben Fähigkeiten, Unteragenten, Hooks und eigene Befehle und installiert alles in einem Schritt. Für eine Komponenten-Bibliothek ist genau das der Unterschied, der im Alltag zählt: Die Werkzeuge allein ändern nichts daran, dass ein Modell eine Sektion lieber selbst schreibt, als zu suchen.

Installiert wird in zwei Zeilen, und dazwischen liegt ein Schritt, den man kennen sollte. Die erste Zeile meldet den Marktplatz an, also den Ort, an dem das Plugin steht, die zweite installiert daraus das Plugin. Seit Claude Code 2.1.275 geht beides auch in einer Zeile, indem man die Quelle mit --marketplace an den Installationsbefehl hängt. In der Sitzung öffnet der Installationsbefehl zuerst die Details, und dort steht, was das Plugin mitbringt, bevor du zustimmst.

Vor dem Zustimmen wählst du den Geltungsbereich, und das ist die eigentliche Entscheidung. Für dich auf diesem Rechner landet in deinen eigenen Einstellungen. Für alle im Repository landet in einer Datei, die du mitcheckst, womit das Plugin für Kolleginnen eingeschaltet ist, aber noch nicht heruntergeladen: Jede führt die Installation einmal selbst aus. Für dich nur in diesem Repository bleibt in den lokalen Einstellungen und geht niemanden sonst etwas an.

Sie hängen die Verbindung an eine Datei statt an ein Konto. Das ist der eine Unterschied, aus dem alle anderen folgen. In Claude verbindest du dich, und die Verbindung gehört dir: Sie ist in jeder Unterhaltung da, auf jedem Gerät, und niemand sonst hat etwas davon. In Cursor und VS Code trägst du den Server in eine Datei ein, und diese Datei liegt entweder im Heimatverzeichnis, dann gilt sie für alle deine Projekte, oder im Projekt, dann gilt sie für alle, die das Projekt öffnen.

Die Formate unterscheiden sich in Details, die man beim Abtippen merkt. Cursor erwartet einen Block mcpServers und darin je Server eine Adresse und optionale Header, in ~/.cursor/mcp.json global oder in .cursor/mcp.json pro Projekt. VS Code erwartet in .vscode/mcp.json einen Block servers, dort zusätzlich eine Angabe type mit http, und kennt daneben einen zweiten Block namens inputs.

Dieser zweite Block ist der eigentlich interessante Teil, denn er löst ein Problem, das Claude gar nicht erst hat. Eine Projektdatei wird mitcheckt, ein Schlüssel darin landet also im Repository. Mit einem Eintrag vom Typ promptString fragt VS Code den Schlüssel beim ersten Start einmal ab, merkt ihn sich lokal und setzt ihn zur Laufzeit ein. In der Datei steht dann nur noch ein Platzhalter. Wer in Cursor denselben Effekt will, legt die Konfiguration ins Heimatverzeichnis statt ins Projekt.

Weil ihm niemand gesagt hat, wann er das tun soll. Dieser Punkt wird in Anleitungen fast immer ausgelassen, und er ist der Grund, warum eine korrekt eingerichtete Verbindung sich anfühlt, als täte sie nichts. Ein verbundener Server erscheint als eine Liste von Werkzeugen. Das Modell sieht diese Liste, aber es hat keinen Anlass, sie zu benutzen, solange die naheliegende Handlung darin besteht, eine Sektion selbst zu schreiben. Es tut dann, was es ohnehin gut kann.

Die Gegenmaßnahme ist eine Datei im Projekt, meist AGENTS.md, in der steht, wann die Bibliothek drankommt. Sie muss nicht lang sein. Drei Anweisungen tragen weit: vor einer neuen Sektion erst suchen, den gelieferten Quelltext übernehmen statt ihn umzuschreiben, und Bilder über das vorgesehene Werkzeug holen. Entscheidend ist die Reihenfolge im Satz, also erst suchen, dann bauen, denn genau diese Reihenfolge ist es, die das Modell von sich aus nicht wählt.

Auf der anderen Seite derselben Leitung steht die Frage, ob die Bibliothek selbst für Modelle lesbar ist. Eine Datei llms.txt auf der Website beantwortet die Fragen, die ein Modell stellt, in der Form, in der es sie stellt: Was ist das, wie viele Bausteine, welche Technik, was kostet es, wie binde ich es ein. Das ist kein SEO-Trick, sondern dieselbe Arbeit wie eine gute Dokumentation, nur für einen Leser, der keine Navigation benutzt und keine zweite Seite aufschlägt.

Fünf Dinge, und keines davon meldet sich mit einer Fehlermeldung. Sie erklären zusammen die meisten Fälle, in denen die Einrichtung stimmt und trotzdem nichts passiert.

Bleibt die Frage, wann sich der ganze Aufwand nicht lohnt. Für ein einzelnes Projekt, in dem drei Komponenten gebraucht werden, ist Kopieren aus dem Browser schneller als jede Einrichtung. Der Nutzen entsteht erst durch Wiederholung, also dort, wo über Wochen immer wieder gesucht, verglichen und eingesetzt wird, und dort, wo mehrere Menschen dieselbe Quelle benutzen sollen.

Und eine Verbindung ersetzt keine Entscheidung. Ein Agent, der auf eine Bibliothek zugreifen kann, baut deshalb noch keine gute Seite: Er findet schneller, was es gibt, und setzt es sauberer ein. Was davon an die richtige Stelle gehört, bleibt eine Frage, die vor dem Werkzeug liegt.