Wie unser MCP-Server ins Connector-Verzeichnis von Claude kam

Unser MCP-Server steht jetzt in Claudes Connector-Verzeichnis. Eine automatische Prüfung hat ihn nach etwa einer Stunde freigegeben. Wir bauen Privatrak, ein cookieloses Analyse-Tool, und MCP (Model Context Protocol) ist der Standard, mit dem sich ein solches Tool an einen KI-Assistenten anschließen lässt. Ist es verbunden, kann Claude Ihre Analyse-Fragen in normaler Sprache beantworten oder das Tracking für Sie einrichten, etwa Funnels, Dashboards und die Frage, welche Klicks zu welchem Feature zählen.

Hier steht, was es wirklich brauchte, um ihn ins Verzeichnis zu bringen, in der Reihenfolge, in der wir darauf stießen. Das meiste gilt für jeden MCP-Server im Netz, nicht nur für Analytics.

Geprüft hat eine KI, kein Mensch

Laut der Freigabe-E-Mail „was reviewed and approved as a community connector by an automated review of the listing“. Die Einreichung wurde also von einer automatischen Prüfung des Eintrags als Community-Connector freigegeben. Auf der Verifizierungsseite erklärt Anthropic, was das heißt. Jede Einreichung wird automatisch auf die Einhaltung der Richtlinien geprüft und standardmäßig als Community-Connector gelistet. Einträge, die für Claude-Nutzer besonders nützlich aussehen, können zu einer Verified-Prüfung hochgestuft werden. Sie ist langsamer, und dort „reviewers run a functional test of each tool“, Prüfer testen also jedes Tool in der Praxis. Auch diese Hochstufung wird automatisch entschieden, man kann sie nicht beantragen.

Das Label ändert weniger, als man denkt. Ist er verbunden, funktioniert ein Community-Connector genauso wie ein Verified-Connector, er taucht in der Suche auf, und Claude kann ihn in einem Chat vorschlagen, wenn er passt. Der Unterschied ist das Label und ein Hinweis, bevor jemand sich verbindet, dass er „hasn’t been reviewed in depth“, also nicht eingehend geprüft wurde. Verified können Sie nicht beantragen. Anthropic wählt Einträge aus, die „highly useful to Claude users“ aussehen, also für Claude-Nutzer besonders nützlich, und sein Entwicklerportal reiht jeden Eintrag danach, wie viele Menschen ihn nutzen. Unsere Wette ist deshalb, dass die Nutzung zählt.

Das ändert, wie man die Einreichung schreibt. Als Erstes liest eine automatische Prüfung Ihre Tool-Beschreibungen gegen die Richtlinie von Anthropic, und deren strengste Regeln betreffen Text, der Claude zu etwas bewegen will, worum der Nutzer nicht gebeten hat (mehr dazu weiter unten). Das Testkonto und den Testplan, nach denen das Formular fragt, schaut sie sich vielleicht auch an, aber nur bei der Verified-Prüfung heißt es ausdrücklich, dass jedes Tool getestet wird. Sie müssen also auch dann funktionieren, wenn Sie nicht dabei sind, um sie zu erklären.

Vor ein paar Monaten sah das noch ganz anders aus. Einreichungen liefen über ein Google-Formular und eine manuelle Warteschlange, und Entwickler berichteten, monatelang gewartet zu haben, ohne eine Antwort zu bekommen. Anthropic hat die Einreichung inzwischen auf ein Portal mit automatischer Prüfung umgestellt, und manche Einreichungen prüft weiterhin ein Mensch, mit Wartezeiten, die von der Warteschlange abhängen. Warum unsere in einer Stunde durchging, wissen wir nicht. Wir vermuten, dass eine saubere Einreichung mit OAuth, ehrlichen Tool-Labels und einem vollständigen Testplan der automatischen Prüfung nichts liefert, was sie an einen Menschen weitergeben müsste.

Warum wir eine Anmeldung mit OAuth brauchten

Claude im Web, die Desktop-App und die mobilen Apps verbinden sich per URL mit einem Server im Netz. Für die meisten Nutzer gibt es keine Stelle, an der sie einen API-Schlüssel einfügen könnten (während wir das schreiben, wird eine Beta, die einen akzeptiert, für einzelne Kunden ausgerollt). Ein Server, der nur Schlüssel akzeptiert, sperrt also die meisten Menschen aus. Und das Verzeichnis verlangt ohnehin OAuth.

Wir haben deshalb die Anmeldung mit OAuth gebaut, denselben Ablauf wie bei jedem „Anmelden mit ...“-Knopf. Claude schickt Sie auf unsere Anmeldeseite, Sie genehmigen den Zugriff, und Claude erhält ein Token für unseren Server. Das haben wir gelernt, als wir es mit den Apps zum Laufen brachten, die Menschen tatsächlich nutzen.

• Claude stellt sich mit einer Webadresse vor. Claude registriert sich nicht vorab bei Ihrem Server. Seine ID ist eine URL, die auf eine kleine Datei mit einer Beschreibung von Claude zeigt (ein Client ID Metadata Document). Sie rufen diese Datei ab und prüfen, ob die Adresse, an die Sie die Leute nach der Anmeldung zurückschicken, darin aufgeführt ist. Cursor und Codex dagegen melden sich spontan selbst an (dynamic client registration). Wenn Sie diese auch unterstützen wollen, brauchen Sie also beides.
• Claude Code wählt einen zufälligen Port. Nach der Anmeldung erwartet es, an http://localhost/callback zurückgeschickt zu werden, auf dem Port, den es gerade geöffnet hat. Die OAuth-Regeln für Desktop-Apps (RFC 8252) sagen, dass der Port bei localhost-Adressen ignoriert wird, und das müssen Sie auch tun, sonst schlägt die Anmeldung von Claude Code fehl.
• Vertrauen Sie dem Namen nicht, den sich eine App gibt. Eine App, die sich spontan registriert, kann sich „Claude“ nennen. Unser Freigabebildschirm zeigt einen Namen nur dann als geprüft an, wenn die Datei, die die App beschreibt, und die Adresse, an die sie zurückkehrt, auf derselben Domain liegen, etwa claude.ai. Sonst zeigt er die Domain neben dem Namen und markiert ihn als nicht geprüft.
• Auf dem Freigabebildschirm entscheiden die Menschen. Unserer fragt, welche Projekte die Verbindung sehen darf und ob sie nur lesen oder auch Änderungen vornehmen darf. Diese beiden Auswahlen entsprechen den zwei Arten von API-Schlüsseln, die wir schon hatten. Eine KI-Verbindung kann also nie mehr als ein Schlüssel.

Im Einreichungsformular war das alles eine einzige Zeile. Hinter dieser Zeile steckte der größte Teil der Arbeit.

Das Häkchen, bei dem wir hängen blieben

Jedes Tool hat eine kurze Beschreibung, die Claude sagt, was es tut und wann man es verwendet. Claude liest diese Beschreibungen fast wie einen Teil seiner Anweisungen, und deshalb prüft das Verzeichnis sie genau. Der letzte Schritt des Formulars hat sieben Kästchen zum Abhaken. Sechs waren einfach. Dieses nicht.

Tool descriptions contain no instructions about model behavior, other tools, or external instruction sources, and no hidden or encoded text.

(Tool-Beschreibungen enthalten keine Anweisungen zum Verhalten des Modells, zu anderen Tools oder zu externen Anweisungsquellen und keinen versteckten oder kodierten Text.)

Wörtlich gelesen, verstoßen unsere gleich zweimal dagegen. Erstens erwähnen manche Tool-Beschreibungen andere Tools, etwa „use the ID you got from start_setup_run“ (nutze die ID aus start_setup_run). Zweitens sagen die allgemeinen Anweisungen, die unser Server Claude gibt, wie es sich verhalten soll, etwa „quote counts with every percentage“ (nenne zu jedem Prozentwert die Zahlen dahinter), damit es „2 von 4 Besuchern“ sagt statt nur „50 %“. Wir wollten beides behalten, weil die Tools damit besser funktionieren.

Wir haben deshalb die Richtlinie gelesen, die das Häkchen zusammenfasst. Ihre tatsächlichen Regeln sind enger.

• Beschreibungen müssen genau sagen, was ein Tool tut und wann man es verwendet, und mit dem übereinstimmen, was es tut.
• Ein Server darf Claude nicht dazu drängen, andere Software aufzurufen, um die der Nutzer nicht gebeten hat, oder die Tools anderer Server stören.
• Er darf Claude nicht anweisen, Verhaltensanweisungen aus externen Quellen zu laden.
• Keine versteckten, verschleierten oder kodierten Anweisungen. Die Richtlinie sagt, „all behavioral guidance must be human-readable and clearly presented“, jede Verhaltensanleitung muss also für Menschen lesbar und klar sichtbar sein.

Die Checkliste vor der Einreichung von Anthropic ist direkter. „Describe what the tool does, and don’t tell Claude how to behave.“ (Beschreiben Sie, was das Tool tut, und sagen Sie Claude nicht, wie es sich verhalten soll.) Am nützlichsten ist aber der letzte Ablehnungsgrund auf ihrer Liste, nämlich Beschreibungen, die „tell Claude to behave in ways unrelated to the tool’s function“, also Claude zu einem Verhalten anweisen, das mit der Funktion des Tools nichts zu tun hat.

Hinweise dazu, was Ihre eigenen Tools tun, sind also erlaubt. Nicht erlaubt sind Hinweise, die Claude von dem wegziehen, worum der Nutzer gebeten hat, hin zu den Tools von jemand anderem, oder die versteckt sind. Auf Ihre eigenen Tools zu verweisen, dem Modell zu sagen, wie es Ihre eigenen Zahlen lesen soll, und es auf Ihre eigene Dokumentation als Nachschlagematerial hinzuweisen ist alles in Ordnung, solange es offen sichtbar ist.

Wir haben das Kästchen angehakt und im Feld für Anmerkungen erklärt, statt zu hoffen, dass es niemand bemerkt. Wir haben aufgeschrieben, auf welche Tools sich unsere Beschreibungen beziehen, warum die Hinweise zur Nutzung da sind und dass unsere beiden Dokumentations-Tools nur unsere eigene öffentliche Dokumentation lesen, aus einer festen Liste von Seiten.

Die automatische Prüfung hat es freigegeben, diese Lesart scheint also zu tragen. Wenn Sie einen Server bauen, schreiben Sie die Beschreibungen so, als läse ein Prüfer jede einzelne, denn einer wird es tun, und der erste ist automatisch. Nennen Sie nur Ihre eigenen Tools, halten Sie alle Hinweise sichtbar, und formulieren Sie einen Satz um, wenn er aus dem Zusammenhang gerissen wie Manipulation klänge.

Wann Claude vor einem Tool nachfragt

Das Verzeichnis verlangt bei jedem Tool drei Angaben, einen title und zwei Hinweise namens readOnlyHint und destructiveHint. Sie entscheiden, wann Claude um Erlaubnis fragt. Laut der Checkliste „can run without per-call confirmation, and destructive tools always prompt“. Nur lesende Tools dürfen ohne Bestätigung bei jedem Aufruf laufen, zerstörerische fragen immer nach. Setzt man sie falsch, müssen die Leute entweder jede harmlose Abfrage bestätigen, oder sie werden nicht gefragt, bevor etwas gelöscht wird.

Warum prüft das Verzeichnis sie so genau? Die MCP-Spezifikation sagt, dass Clients diese Hinweise als nicht vertrauenswürdig behandeln müssen, solange sie nicht von einem vertrauenswürdigen Server stammen, und trotzdem entscheidet Claude anhand davon, wann es fragt. Wir vermuten, dass die Prüfung es ist, die einem Server dieses Vertrauen verschafft.

Eines sollte man beachten. Wenn Sie destructiveHint bei einem schreibenden Tool nicht setzen, nimmt das Protokoll an, dass es zerstörerisch ist. Das ist ein sicherer Standard, beschreibt aber ein Tool wie „Dashboard anlegen“ falsch. Wir setzen deshalb beide Hinweise bei jedem schreibenden Tool ausdrücklich.

• Etwas anzulegen ist nicht zerstörerisch, und wer es zweimal ausführt, hat zwei davon.
• Ändern, Umbenennen, Löschen und Rückgängigmachen sind zerstörerisch, und zweimal ausgeführt bewirken sie nicht mehr als einmal.
• Manche Tools verdienen einen genaueren Blick. In Privatrak ist ein Klickproblem etwas, das Menschen anklicken und das nicht funktioniert. Eines als behoben zu markieren ist zerstörerisch, und zweimal ist nicht dasselbe wie einmal, denn es verschiebt das Datum, ab dem das Problem als erneut aufgetreten gilt. Es zweimal als ignoriert zu markieren ändert beim zweiten Mal tatsächlich nichts.

Ein Testkonto einrichten

Zugangsdaten zum Testen sind Pflicht, und laut Checkliste „must be for a fully populated account“, müssen also zu einem vollständig befüllten Konto gehören. Bei Analytics ist das wichtiger als bei den meisten Tools, denn ein leeres Projekt beantwortet jede Frage mit null.

Für uns war das einfach, weil wir schon eine öffentliche Demo mit einem Beispiel-Shop und seinem Verkehr betreiben. Wir haben ein eigenes Konto im Pro-Tarif angelegt, mit einem Projekt, das einen Monat derselben Art von Shop-Verkehr enthält, mit Besuchern aus der Suche und aus Kampagnen, Produktseiten, einen Checkout-Funnel, Wege durch die Seite und ein paar kaputte Buttons für die Klickproblem-Tools. Über ein Detail wären wir fast gestolpert. Unsere Funnels zählen nur ab dem Tag, an dem sie angelegt wurden. Ein Funnel, der am Tag der Einreichung hinzugekommen wäre, hätte also nichts gezeigt. Alles im Prüfprojekt musste aussehen, als wäre es den ganzen Monat über schon da gewesen.

Geben Sie dem Konto eine einfache E-Mail-Adresse mit Passwort. Ein Team wurde abgelehnt, weil sein Prüfkonto die Anmeldung mit Google nutzte, mit einem Code, der aufs Handy geschickt wurde, an dem der Prüfer nicht vorbeikam. Der Server selbst war in Ordnung.

Einen Testplan schreiben

Das Formular fragt, wie man den Server testet. Unser erster Entwurf war eine Handvoll Beispiel-Prompts, und die waren nutzlos. Fünf schöne Prompts prüfen vielleicht ein Dutzend Tools. Sie zeigen, dass der Server funktioniert, nicht dass jedes Tool es tut.

Wir schrieben deshalb einen Plan mit 15 Prompts, die zusammen alle 44 Tools aufrufen, jeweils mit den Tools, die sie auslösen, und der Antwort, die wir bekamen, damit der Prüfer nachprüfen kann, statt zu raten. Hier ist Schritt 4.

4. "Which properties can I filter by, and which page paths exist? Then chart
   page views and clicks per day from 2026-10-13 to 2026-10-19 and compare
   them with the week before."
   Tools: list_property_keys, list_property_values, run_insights_query.
   Expect: 162 page views (+25.6%), 53 clicks (+23.3%).

Feste Daten sind hier wichtig. „Letzte Woche“ bedeutet an jedem Tag, an dem der Prüfer den Plan öffnet, etwas anderes.

Der schwierigere Teil sind die schreibenden Tools. Ein Prüfer muss Dinge anlegen, ändern und löschen, um sie zu testen, auf einem Konto, das nach ihm andere Prüfer benutzen könnten. Hinterlässt der Plan Chaos, schlägt der zweite Durchlauf fehl.

Hier zahlte sich eine Entscheidung aus, die Monate zurücklag. In Privatrak gehört jede Änderung eines Assistenten zu einem Setup-Lauf, und ein Setup-Lauf lässt sich in einem Schritt rückgängig machen. Rückgängigmachen stellt genau das wieder her, was der Lauf geändert hat. Hat jemand dasselbe seither geändert, überspringt es diesen Eintrag und sagt es, statt dessen Arbeit zu überschreiben. Das Rückgängig-Tool zeigt zuerst, was es tun würde, und tut es erst dann.

Der letzte Schritt des Plans räumt deshalb hinter allem anderen auf.

15. "List the setup runs and show what 'Review test' changed. Then undo it:
    dry run first, then for real."
    Tools: list_setup_runs, get_setup_run, undo_setup_run.
    Expect: 15 changes listed; the undo reverts all 15 with nothing skipped.
    The project is back to its original state.

Den ganzen Plan haben wir vor der Einreichung selbst durch Claude laufen lassen, angemeldet als das Prüfkonto. Der Schritt „Test & launch“ des Formulars verlangt die Bestätigung, dass Sie jedes Tool getestet haben, und so konnten wir mit Ja antworten. Jedes Tool bestand, und das Rückgängigmachen ließ das Projekt genau so zurück, wie es war. Der Plan lässt sich beliebig oft ausführen.

Ob die automatische Prüfung ihn angesehen hat, wissen wir nicht. Wir würden ihn trotzdem wieder schreiben. Ihm würde ein Verified-Prüfer folgen, und nur so wussten wir, dass alle 44 Tools über Claude selbst funktionieren, nicht nur in unseren eigenen Tests.

Wir haben Setup-Läufe für Kunden gebaut, nicht für Prüfer. Eine KI Ihre Analytics-Einrichtung ändern zu lassen ist nur vernünftig, wenn Sie alles zurücknehmen können. Aber wenn Ihr Server schreibende Tools hat und keine Möglichkeit, sie rückgängig zu machen, überlegen Sie, wie ein Prüfer sie testen soll. Und dann, wie Ihre Nutzer ihnen vertrauen sollen. Wie unser Rückgängigmachen funktioniert, haben wir in einem eigenen Artikel beschrieben.

Kleinigkeiten, die uns einen Nachmittag kosteten

• Claude Code brauchte 25 Sekunden zum Verbinden. Die Ursache war eine einzige Standardeinstellung. Das Go-SDK, das wir nutzen, teilt jedem Client mit, dass sich unsere Tool-Liste ändern kann, während er verbunden ist (listChanged: true). Claude Code wartete auf ein Update, das nie kam, und gab nach etwa 25 Sekunden auf. Unsere Tool-Liste ändert sich nie, also schalteten wir die Einstellung aus (listChanged: false), und Claude Code verbindet sich jetzt sofort.
• Claudes Desktop-App sendet Ihren API-Schlüssel nicht an der üblichen Stelle. Man kann dort einen eigenen Connector mit zusätzlichen Request-Headern hinzufügen, aber nicht den Header Authorization, in dem API-Schlüssel normalerweise stehen. Wir akzeptieren den Schlüssel deshalb auch in einem Header X-API-Key, den unsere API schon verwendete. Wer lieber einen Schlüssel nutzt, statt sich anzumelden, kann sich weiterhin verbinden.

Und die offizielle MCP Registry?

Eines hat uns am Anfang verwirrt. Neben dem Verzeichnis von Anthropic gibt es die offizielle MCP Registry (registry.modelcontextprotocol.io), eine öffentliche Liste von MCP-Servern, betrieben von den Leuten hinter dem Protokoll. Beide sind getrennt. Die Registry verlangt einen Nachweis, dass Ihnen der Name gehört, unter dem Sie veröffentlichen, und das Formular von Anthropic erwähnt die Registry überhaupt nicht.

Wir haben beides gemacht. Um in der Registry als com.privatrak/analytics zu veröffentlichen, mussten wir nachweisen, dass wir privatrak.com kontrollieren. Dazu legen Sie bei Ihrer Domain einen DNS-Eintrag mit einem öffentlichen Schlüssel an und melden sich dann mit dem passenden privaten Schlüssel über das Tool mcp-publisher der Registry an. Der einzige Haken war, dass das Tool den privaten Schlüssel als Hex-Wert braucht, und der Befehl dafür aus der Anleitung funktionierte mit unserer OpenSSL-Version nicht. Dieser hier funktioniert mit jeder Version.

openssl pkey -in key.pem -outform DER | tail -c 32 | xxd -p -c 64

Der Registry-Eintrag selbst ist eine kleine server.json mit Name, Titel, einer einzeiligen Beschreibung, Ihrer Website, einem Symbol und der Adresse Ihres Servers. Schreiben Sie die Beschreibung für jemanden, der entscheidet, ob er Sie installiert, nicht für Suchmaschinen. Unsere lautet „Ask your website analytics in plain language and set up funnels, features and dashboards.“ (Stellen Sie Fragen an Ihre Website-Analyse in normaler Sprache und richten Sie Funnels, Features und Dashboards ein.)

Eine Checkliste für Ihre Einreichung

1. Die Checkliste von Anthropic vor der Einreichung neben dem Formular geöffnet. Sie sagt ausdrücklich, was die Richtlinie nur andeutet.
2. Eine OAuth-Anmeldung, die für Claude (Client ID Metadata Documents) und für Cursor und Codex (Dynamic Registration) funktioniert und bei localhost-Adressen den Port ignoriert.
3. Der aktuelle MCP-Transport, Streamable HTTP. Ändert sich Ihre Tool-Liste nie, setzen Sie listChanged: false.
4. Ein title, readOnlyHint und destructiveHint bei jedem Tool, bewusst gesetzt.
5. Tool-Beschreibungen, die sich nur auf Ihre eigenen Tools beziehen, mit allen Hinweisen offen sichtbar. Erklären Sie alles Grenzwertige in den Anmerkungen.
6. Ein Testkonto mit realistischen Daten und Daten im Testplan, die nicht wandern.
7. Ein Testplan, der jedes Tool aufruft, mit erwarteten Antworten, und der hinter sich aufräumt.
8. Optional ein Eintrag in der offiziellen MCP Registry, über einen DNS-Eintrag bei Ihrer Domain.
9. Eine öffentliche Datenschutzerklärung, in der Einreichung verlinkt.
10. Ein Prüfkonto mit einfacher E-Mail-Adresse und Passwort, ohne Anmeldung über Google und ohne Codes aufs Handy.
11. Geduld bei späteren Änderungen. Eine neue Beschreibung oder neue Screenshots prüft ein Mensch, und das kann Wochen dauern, während Ihr Eintrag online bleibt.

Wenn Sie sehen möchten, wie das aus Sicht der Nutzer aussieht, finden Sie Privatrak jetzt als Community-Connector im Verzeichnis. Unsere Dokumentation zeigt, wie Sie ihn verbinden.