Namefi

Namefi MCP-Schnellstart: Claude Code, Cursor & Windsurf

MCP-Einrichtung je Editor für Claude Code, Cursor und Windsurf, gefolgt von einem 5-Schritte-Schnellstart von einer neuen App bis zu einer live geschalteten benutzerdefinierten Domain — ohne den Editor zu verlassen.

Fenwei BianFenwei BianAutor*inVictor ZhouVictor ZhouRedaktionKai KunstmannKai KunstmannÜbersetzung10. Juli 2026ca. 9 Min. Lesezeit
  • ai-agents
  • guide
Auf X teilen

Du bist bereits im Editor. Die App ist eingerichtet, das erste Deployment ist gerade auf einer Plattform-Subdomain live gegangen, und bevor du Menschen darauf verweisen kannst, fehlt nur noch eine echte Domain. Dieser Schnellstart zeigt, wie du diesen Registrierungsschritt erledigst, ohne einen Browser-Tab zu öffnen, ein Checkout-Formular auszufüllen oder dieselbe KI-Agent-Sitzung zu verlassen, die die App erstellt hat: die exakte MCP-Verbindungskonfiguration für Claude Code, Cursor und Windsurf, ein komprimierter Ablauf in fünf Schritten und — der Teil, den die meisten Domain-Leitfäden überspringen — wie du die gerade registrierte Domain tatsächlich auf das gerade ausgelieferte Deployment zeigst.

Dieser Leitfaden behandelt bewusst drei Editoren. Falls du stattdessen OpenAI Codex, Gemini CLI oder Claude Desktop nutzt, ist Wie du mit deinem KI-Agenten eine Domain bei Namefi registrierst der zentrale Leitfaden mit einer verifizierten Einrichtung für alle sechs Clients sowie dem direkten REST-Weg für alles, was nicht MCP-nativ ist. Alles hier verbindet sich mit demselben Namefi-MCP-Server, den dieser zentrale Leitfaden dokumentiert. Daher widerspricht nichts weiter unten ihm — diese Seite ist lediglich die verdichtete, auf Entwicklertools ausgerichtete Fassung mit einem Deployment-Schritt, den der zentrale Leitfaden nicht behandelt.

Warum die Domain im Editor registrieren

„Registriere eine Domain“ ist für eine Fünf-Minuten-Aufgabe ein Kontextwechsel mit ungewöhnlich hohen Kosten: Du verlässt den Editor, öffnest die Website eines Registrars, suchst einen Namen, durchläufst einen Upsell-Funnel für Datenschutz und E-Mail-Hosting, nach denen du nicht gefragt hast, bezahlst und kommst dann zurück, um herauszufinden, welche DNS-Einträge du hinzufügen musst.

Die Alternative ist, denselben Agenten, der das Projekt eingerichtet und das Deployment aufgesetzt hat, auch die letzte Meile erledigen zu lassen: den Namen prüfen, registrieren und DNS einrichten — alles als Tool-Aufrufe in der Unterhaltung, die du bereits führst. Cloudflare vermarktet eine Variante derselben Idee für seine eigene Registrar API — ein Beleg dafür, dass dies keine Nischenpräferenz, sondern ein Workflow ist, auf den mehr als ein Registrar hinarbeitet. Der Vergleichsabschnitt gegen Ende behandelt speziell den Cloudflare-Ansatz; die Version von Namefi ergänzt eine Option für tokenisierte Domains und einen per Wallet-Signatur autorisierten Zahlungsweg ganz ohne Konto, erläutert in Domains mit einer Krypto-Wallet bezahlen.

Die Verbindung einrichten: drei Editoren, drei Konfigurationsdateien

Alle drei nachstehenden Editoren verbinden sich über Streamable HTTP mit demselben Endpoint, https://api.namefi.io/mcp. Dein Namefi-API-Key wird dabei als x-api-key-Header gesendet. Je Editor unterscheiden sich nur das Dateiformat und der Befehl, der es schreibt.

Claude Code

Die eigene Dokumentation von Claude Code enthält einen direkten CLI-Befehl, um einen Remote-HTTP-Server mit einem benutzerdefinierten Header hinzuzufügen:

claude mcp add --transport http namefi https://api.namefi.io/mcp --header "x-api-key: YOUR_KEY"

Führe ihn einmal aus einem Terminal in deinem Projekt aus und ersetze den Platzhalter durch deinen echten Schlüssel. Standardmäßig schreibt er den Server im lokalen Scope — nur für dich und nur in diesem Projekt verfügbar. Füge --scope user hinzu, um ihn stattdessen für jedes Projekt auf deinem Rechner verfügbar zu machen, und bestätige die Verbindung mit claude mcp list.

Cursor

Cursor liest MCP-Server aus mcp.json — einer Projektkopie unter .cursor/mcp.json oder einer globalen Kopie unter ~/.cursor/mcp.json. Das dokumentierte Format für Remote-Server unterstützt Header-basierte Authentifizierung mit Umgebungsvariablen-Interpolation, sodass der Schlüssel selbst nicht in der Datei stehen muss:

{
  "mcpServers": {
    "namefi": {
      "url": "https://api.namefi.io/mcp",
      "headers": {
        "x-api-key": "${env:NAMEFI_API_KEY}"
      }
    }
  }
}

${env:NAMEFI_API_KEY} wird aus dem Wert aufgelöst, den diese Variable in der Shell hat, die Cursor gestartet hat — exportiere sie, bevor du den Editor öffnest.

Windsurf (Cascade)

Die MCP-Integration von Windsurf — als Cascade vermarktet — liest ~/.codeium/windsurf/mcp_config.json. Remote-Server verwenden dort statt url ein Feld serverUrl, mit demselben Muster aus headers und ${env:VAR} wie bei Cursor:

{
  "mcpServers": {
    "namefi": {
      "serverUrl": "https://api.namefi.io/mcp",
      "headers": {
        "x-api-key": "${env:NAMEFI_API_KEY}"
      }
    }
  }
}

Ein wichtiger Hinweis: Zum Veröffentlichungsdatum dieses Leitfadens leitet docs.windsurf.com/windsurf/cascade/mcp auf docs.devin.ai/desktop/cascade/mcp weiter. Die Windsurf-Dokumentation liegt nun unter der Produktdokumentationsdomain von Cognition Devin, und das obige Konfigurationsformat ist das, was die aktuelle Seite dokumentiert. Falls du einen älteren Build nutzt, überprüfe die Feldnamen anhand des Dokumentationslinks, auf den die In-App-Hilfe deiner Version verweist.

Der Schnellstart in fünf Schritten: von einer neuen App zu live geschaltetem DNS

Sobald eine der obigen Verbindungen aktiv ist, bleibt der restliche Ablauf gleich, unabhängig vom verwendeten Editor.

  1. Besorge einen API-Key über namefi.io/api-key, erzeugt aus der Wallet, der die neue Domain gehören soll.
  2. Verbinde dich mit der Konfiguration für deinen Editor und führe dann einen Plausibilitätscheck durch: Frage „Prüfe, ob <yourapp>.com auf Namefi verfügbar ist, und sage mir, welches Tool du aufgerufen hast.“ Das ist ein schreibgeschützter checkAvailability-Aufruf und funktioniert daher, bevor du etwas finanziert hast.
  3. Registriere. Bestätige Name und Laufzeit in natürlicher Sprache — „Registriere sie für ein Jahr.“ Der Agent sendet registerDomain und fragt die Bestellung ab, bis sie SUCCEEDED erreicht (oder einen terminalen Fehlerzustand); eine typische Registrierung wird nach einer Handvoll Abfragezyklen abgeschlossen.
  4. Zeige die Domain auf dein Deployment. Dieser Schritt wird im nächsten Abschnitt ausführlich behandelt — füge die DNS-Einträge hinzu, die deine Hosting-Plattform verlangt, über dieselbe Unterhaltung.
  5. Prüfe die Auflösung. DNS-Propagierung erfolgt nicht sofort. Warte daher ein paar Minuten und bestätige sie dann mit einer öffentlichen DNS-Abfrage oder indem du die Domain einfach im Browser lädst.

Die neue Domain auf das gerade ausgelieferte Deployment zeigen

Hierauf kommt ein allgemeiner Leitfaden zu „Wie registriere ich eine Domain?“ nie, weil es nach der Registrierung auf Seiten der Hosting-Plattform geschieht. Es ist jedoch der eigentliche Sinn, dies im Editor zu erledigen: Dein Agent weiß bereits, auf welcher Plattform er deployed hat, und kann das DNS im selben Atemzug wie die Registrierung einrichten.

Vercel

Die eigene Domain-Dokumentation von Vercel führt durch den Ablauf über Settings → Domains im Projekt-Dashboard: Füge die Domain hinzu, und Vercel zeigt dir, welchen Eintrag du erstellen musst, je nachdem, ob es sich um eine Apex-Domain oder eine Subdomain handelt. Für eine Apex-Domain (yourapp.com) verlangt Vercel einen A-Eintrag, der auf seine Serving-IP zeigt; für eine Subdomain (www.yourapp.com) verlangt es einen CNAME. Bevor du ein Beispiel aus einem älteren Leitfaden übernimmst, solltest du wissen: Die Vercel-Dokumentation stellt ausdrücklich klar, dass dieses CNAME-Ziel für jedes Projekt eindeutig ist. Es wird im Dashboard angezeigt, statt dass es einen einzelnen festen Hostnamen gibt, den alle Projekte teilen.

Sobald du diesen Wert hast, ist die DNS-Seite eine weitere Anfrage an den Agenten:

„Füge einen A-Eintrag für @ hinzu, der auf 76.76.21.21 zeigt, und einen CNAME für www, der auf das CNAME-Ziel zeigt, das Vercel mir gegeben hat.“

Das ruft createDnsRecord zweimal auf — einmal pro Eintrag —, dasselbe DNS-Eintrag-Tool, das für jeden DNS-Schreibvorgang auf Namefi verwendet wird. Die Regel zum abschließenden Punkt gilt hier wie überall: rdata für ein CNAME-Ziel benötigt einen abschließenden Punkt, zoneName (deine Domain) nicht.

Cloudflare Pages

Wenn dein Deployment-Ziel stattdessen Cloudflare Pages ist und das DNS deiner Domain nicht bereits auf Cloudflare verwaltet wird, verlangt die eigene Dokumentation von Cloudflare zu Custom Domains einen einzelnen CNAME-Eintrag, der auf die .pages.dev-Subdomain deines Projekts zeigt. Ein A-Eintrag ist nicht nötig, da Pages alles über dieses CNAME-Ziel ausliefert. Der Schritt im Cloudflare-Dashboard (Workers & Pages → dein Projekt → Custom domains → Set up a domain) muss zuerst erfolgen; erst dann löst das CNAME-Ziel korrekt auf.

„Füge einen CNAME für app hinzu, der auf my-project.pages.dev. zeigt.“

Derselbe Tool-Aufruf, dieselbe Regel zum abschließenden Punkt beim Ziel, andere Plattform.

Wie dies mit der Registrierung im Editor bei Cloudflare verglichen werden kann

Cloudflare ist der andere Registrar, der einen Ansatz im Editor aktiv vermarktet, und verdient eine direkte Erwähnung. Seine Registrar API, die laut Bericht seit April 2026 in der Beta ist, integriert sich ebenfalls mit MCP-fähigen Editoren einschließlich Cursor und Claude Code. Damit kann ein Agent eine Domain suchen, bepreisen und synchron registrieren, ohne den aktuellen Kontext zu verlassen — dieselbe Kernidee, die dieser Leitfaden für Namefi durchgeht. Derselbe Bericht weist darauf hin, dass die API von Cloudflare in der Beta die Verwaltung nach der Registrierung wie Transfers und Verlängerungen noch nicht abdeckt; sie ist für später 2026 geplant.

Der MCP-Server von Namefi deckt heute den gesamten Lebenszyklus ab — Registrierung, DNS, Auto-Renew — sowie zwei Dinge, die der Weg über Cloudflare nicht bietet: Die Domain wird standardmäßig als NFT registriert und damit zu einer tokenisierten Domain (auf jede Wallet umleitbar), und er unterstützt einen per Wallet-Signatur autorisierten Checkout ganz ohne Namefi-Konto, ausführlich beschrieben in Domains mit einer Krypto-Wallet bezahlen. Beide bauen auf denselben „Editor nicht verlassen“-Workflow hin; welcher passt, hängt davon ab, ob du eine Standardregistrierung oder eine Registrierung möchtest, die zugleich ein On-Chain-Asset ist.

Häufig gestellte Fragen

Deckt dies auch Codex oder Gemini CLI ab?

Nicht hier — dieser Leitfaden beschränkt sich bewusst auf Claude Code, Cursor und Windsurf. Wie du mit deinem KI-Agenten eine Domain bei Namefi registrierst enthält dieselbe exakte, verifizierte Konfiguration für Codex CLI, Gemini CLI und Claude Desktop.

Benötige ich ein Namefi-Konto, bevor ich dies ausprobieren kann?

Nein. Eine schreibgeschützte Verfügbarkeitsabfrage benötigt keine Authentifizierung. Du kannst daher jeden der obigen Editoren verbinden und den Test-Prompt aus Schritt 2 ausführen, bevor du einen API-Key erzeugst oder etwas finanzierst.

Was ist, wenn meine Deployment-Plattform nicht Vercel oder Cloudflare Pages ist?

Das Muster gilt überall: Das Dashboard deiner Plattform sagt dir, welchen DNS-Eintragstyp es benötigt — fast immer einen A-Eintrag für eine Apex-Domain oder einen CNAME für eine Subdomain — und du gibst diesen Wert an deinen Agenten weiter, damit er ihn über createDnsRecord schreibt.

Wird die Domain bei dieser Registrierung automatisch tokenisiert?

Ja, standardmäßig — die Domain wird als NFT auf Base in die an deinen API-Key gebundene Wallet registriert, sofern du in der Anfrage keine andere nftReceivingWallet angibst. Wenn das neu für dich ist, lies Was sind tokenisierte Domains?.

Kann ich den API-Key vollständig überspringen?

Ja, mit einer Einschränkung: Der per Wallet-Signatur autorisierte x402-Checkout-Weg von Namefi ermöglicht es einer finanzierten Wallet, eine Registrierung ganz ohne Konto oder API-Key zu bezahlen. Er braucht eine eigene Erklärung; diese findest du in Domains mit einer Krypto-Wallet bezahlen.

Den Namen mit der App ausliefern

Die Domain ist Infrastruktur, genauso wie das Deployment-Ziel und die Datenbank. Es gibt keinen überzeugenden Grund, warum sie das eine Teil beim Ausliefern einer App sein sollte, das weiterhin verlangt, deine Tools zu verlassen und ein Webformular auszufüllen. Verbinde eine der drei obigen Konfigurationen, führe den Ablauf in fünf Schritten aus, und die Domain geht live, auf dasselbe Deployment gerichtet, das dein Agent gerade erstellt hat — ohne einen einzigen Browser-Tab.

Einen Namefi API-Key erzeugen — und probiere den Prompt zur Verfügbarkeitsabfrage in dem Editor aus, den du bereits geöffnet hast. Wenn du jeden Schritt im Detail sehen möchtest, lies die vollständige Claude-Code-Anleitung mit kommentiertem Transkript.

Quellen und weiterführende Lektüre

Mitwirkende

Fenwei Bian
Fenwei BianAutor*in
Softwareentwicklerin und Autorin • Namefi

Fenwei Bian ist eine Softwareentwicklerin in ihren Dreißigern, die ihre Arbeitszeit mit Pull Requests und ihre Wochenenden mit den Händen in Erde oder Sägemehl verbringt. Durch ihre jahrelange Arbeit an Open-Source-Projekten auf GitHub hat sie gelernt, dass Namen Schnittstellen sind: Ein guter Name ist klar, vermittelt ehrlich, was er tut, und nimmt Rücksicht auf alle, die ihn als Nächstes verwenden müssen.

Sie gärtnert, weil es Geduld belohnt und Wunschdenken bestraft, und sie arbeitet mit Holz, weil eine Verbindung entweder passt oder eben nicht. Beide Gewohnheiten prägen ihre Texte über Namensgebung: zweimal messen, die Quelle prüfen und eine raue Stelle nicht einfach abschleifen in der Hoffnung, dass sie niemandem auffällt.

Für Namefi schreibt sie darüber, wie sich Domainmärkte tatsächlich bewegen, welche praktischen Abwägungen mit der Tokenisierung und dem Weiterverkauf von Namen verbunden sind und wie man eine Domain auswählt, über deren Besitz man sich auch in zwanzig Jahren noch freuen wird.

Victor Zhou
Victor ZhouRedaktion
Gründer und Redakteur für technische Standards • Namefi

Victor Zhou ist Technologiegründer und Redakteur für technische Standards mit dem Schwerpunkt auf digitaler Identität und Vertrauen. Er gründete Namefi, redigiert Ethereum Improvement Proposals und leitete zuvor bei Google Labs die Arbeit an Smart-Contract-Architekturen.

Seine Arbeit liegt an der Schnittstelle von Namensgebung, Eigentum und den Systemen, mit denen Menschen ihre Identität online nachweisen. Diese Perspektive weckt sein besonderes Interesse daran, wie Namen zwischen persönlicher Bedeutung, öffentlicher Wiedererkennung und digitaler Infrastruktur wandern.

Für Namefi redigiert und schreibt Victor über Domains als dauerhafte digitale Identität: darüber, wie Namen zu besitzbaren Onchain-Assets werden, wie Tokenisierung Verwahrung und Vertrauen verändert und was Namensgebung von den Systemen lernen kann, mit denen Menschen ihre Identität online nachweisen.

Kai Kunstmann
Kai KunstmannÜbersetzung
Übersetzer für deutsche Lokalisierung • Namefi

Kai Kunstmann ist ein technischer Übersetzer Mitte dreißig und lebt in Leipzig. Er absolvierte eine Ausbildung zum Mechatroniker in einem mittelständischen Maschinenbauunternehmen und schrieb und übersetzte jahrelang Maschinenhandbücher, bevor er zur Lokalisierung von Software und redaktionellen Inhalten zwischen Englisch und Deutsch wechselte.

Er arbeitet mit der Präzision eines guten Handbuchs: einheitliche Terminologie, keine falschen Freunde und zusammengesetzte Wörter, die ein deutscher Leser auf Anhieb versteht. Er pflegt einen Schrebergarten, restauriert alte Fahrräder und braut sein eigenes Bier — Hobbys, bei denen es sich auszahlt, vor dem Schneiden genau zu messen.

Für Namefi lokalisiert er Texte über Domains und Namensgebung ins Deutsche. Er achtet besonders auf den Umgang mit IDNs und Umlauten (ä→ae), den Unterschied zwischen .de und .eu sowie auf Markennamen, die aus den langen Zusammensetzungen entstehen, die im Deutschen so gut funktionieren.

Verwandte Leitfäden

Diskutiere diesen Beitrag

Diskussion auf Namefi Discuss ansehen