Drei Möglichkeiten, auf Wikiprompt zuzugreifen: Bulk-Dataset, Such-API und MCP

Drei Möglichkeiten für den Zugriff auf Wikiprompt: Bulk-Datensatz, Such-API und MCP

Wikiprompt hat jetzt über 55.000 kuratierte KI-Prompts hinter drei verschiedenen Türen, und die falsche zu wählen ist der einfachste Weg, einen Nachmittag zu verschwenden. Wenn du einen Scraper schreibst, der /search in einer Schleife abfragt, um den gesamten Katalog lokal neu aufzubauen, wirst du irgendwann rate-limited und hast etwas neu erfunden, das wir bereits für dich gebaut haben. Wenn du den gesamten Datensatz nur herunterlädst, um eine einzelne Abfrage zur Laufzeit in einem Chat-Agenten zu beantworten, hast du 55.000 Datensätze verschickt, um eine Frage zu beantworten, die drei gebraucht hätte.

Die richtige Wahl hängt vollständig von der Form deines Problems ab: Brauchst du alles, brauchst du eine Antwort auf eine Frage, oder brauchst du ein Werkzeug, das ein Sprachmodell selbst aufrufen kann. Hier ist, wie die drei Integrationspfade diesen drei Bedürfnissen entsprechen.

Pfad 1: der Bulk-Datensatz, wenn du den gesamten Katalog brauchst

Nutze dies, wenn du mit Prompt-Daten trainierst, deinen eigenen Suchindex baust, Analysen über das Korpus durchführst oder den Katalog in deine eigene Datenbank spiegelst. Es ist die Option "einmal herunterladen, Daten besitzen".

Beginne mit dem Manifest des Datensatzes. Es gibt JSON mit total_prompts, den record_fields, die du zurückbekommst, und dem Paginierungsschema zurück, sodass du die Struktur überprüfen kannst, bevor du etwas abrufst.

Die eigentlichen Datensätze liegen unter /dataset/prompts. Die Paginierung ist keyset-basiert: Jede Antwort enthält eine next-URL, und du folgst ihr, bis next null zurückgibt. Die Seitengröße beträgt standardmäßig 200 und kann bis zu 500 betragen:

curl "https://www.wikiprompt.org/dataset/prompts?limit=500"

Eine minimale Paginierungsschleife in Python sieht so aus:

import requests

url = "https://www.wikiprompt.org/dataset/prompts?limit=500"

records = []

while url:

resp = requests.get(url).json()

records.extend(resp["results"])

url = resp.get("next")

print(len(records), "prompts pulled")

Jeder Datensatz enthält slug, url, title, description, content (den eigentlichen Prompt-Text), category, tags, media, model, strukturierte metadata (Medientyp, Seitenverhältnis, Stil, Qualitätsbewertung), author, original_source und Zeitstempel. Kein API-Schlüssel, CORS ist vollständig offen, und Antworten sind edge-cached, sodass ein vollständiger Abruf schnell ist und keine echte Last auf unseren Servern erzeugt.

Der Nachteil ist die Aktualität. Ein Bulk-Abruf ist eine Momentaufnahme. Wenn du den Zustand des Katalogs von vor fünf Minuten brauchst, ist dies das falsche Werkzeug - du willst eines der nächsten beiden.

Pfad 2: die Such-API, wenn du gezielte Antworten brauchst

Nutze dies, wenn deine Integration nur eine Handvoll Prompts pro Anfrage benötigt, zum Beispiel ein "Prompt des Tages"-Widget, ein Slack-Bot, der "finde mir einen Logo-Prompt" beantwortet, oder eine Funktion, die relevante Prompts in deinem eigenen Produkt anzeigt. Den gesamten Datensatz dafür herunterzuladen ist verschwendete Bandbreite und verschwendete Wartung (du müsstest ihn ständig neu synchronisieren).

Der Endpunkt ist https://www.wikiprompt.org/api/search?q=YOURQUERY, einfaches JSON, keine Authentifizierung. Eine Abfrage für einen Logo-Prompt:

curl "https://www.wikiprompt.org/api/search?q=logo"

Dies ist eine Live-Abfrage gegen den aktuellen Katalog, sodass ein vor einer Stunde veröffentlichter Prompt sofort erscheint, anders als eine Datensatz-Momentaufnahme, die du letzte Woche abgerufen hast. Es ist auch auf beiden Seiten günstig: Du bekommst eine Handvoll Treffer zurück, anstatt Tausende von Datensätzen clientseitig zu parsen, um die zwei zu finden, die relevant sind. Wenn deine Integration anfragegesteuert ist (ein Benutzer tippt etwas, du brauchst ein Ergebnis), ist dies fast immer die richtige Wahl.

Pfad 3: der MCP-Server, wenn der Aufrufer ein KI-Agent ist

Nutze dies, wenn Claude oder ein anderer MCP-fähiger Agent im Rahmen eines Gesprächs auf Wikiprompt browsen oder daraus ziehen muss, nicht als Backend-Job, den du geschrieben hast und kontrollierst. Der MCP-Server stellt Prompt-Entdeckung als Werkzeuge bereit, die ein Agent selbstständig aufrufen kann, mitten im Gespräch, basierend auf dem, was der Benutzer tatsächlich gefragt hat.

Richte einen MCP-Client auf https://mcp.wikiprompt.org/mcp (Streamable HTTP) aus, und der Agent erhält Werkzeuge wie search_prompts, get_prompt, list_categories, get_featured, get_trending und random_prompt, plus eine use_prompt(slug)-Prompt-Vorlage. Von der CLI:

claude mcp add --transport http wikiprompt https://mcp.wikiprompt.org/mcp

Sobald verbunden, kann ein Agent, der ein Charakterdesign erstellt, search_prompts für Inspiration aufrufen und etwas wie diese Charakterbeschreibung eines nomadischen Reisenden zurückbekommen, ohne dass du eine einzige Zeile Integrationscode schreibst. Der Datensatz und die Such-API erfordern beide, dass du den aufrufenden Code schreibst und entscheidest, wann du aufrufst. MCP kehrt das um: Der Agent entscheidet, im Moment, in dem er es braucht, welches Werkzeug er mit welchen Argumenten aufruft. Das ist der ganze Sinn, für Agenten statt für Skripte zu bauen.

Auswahl zwischen ihnen

Eine grobe Regel: Datensatz für Bulk, Such-API für einmalige Abfragen aus deinem eigenen Backend, MCP für alles, bei dem ein KI-Agent entscheidet, was abgerufen wird. Einige konkrete Fälle:

Sie schließen sich nicht gegenseitig aus. Ein einzelnes Produkt könnte den Bulk-Datensatz einmal pro Woche abrufen, um seine eigene Empfehlungsfunktion zu betreiben, eine Live-Suchbox gegen /api/search bereitstellen und separat den MCP-Server registrieren, damit seine KI-Funktionen direkt auf den aktuellen Katalog zugreifen können. Nichts daran, eines zu wählen, schließt dich von den anderen aus.

Welchen Pfad du auch nutzt, der Inhalt ist aus öffentlichen Beiträgen echter Personen aggregiert, nicht von ihnen lizenziert, also spiele fair: Gib wikiprompt.org und, pro Datensatz, die original_source, aus der der Prompt tatsächlich stammt, als Quelle an. Wenn du vor dem Code einen genaueren Blick darauf werfen möchtest, wie ein Datensatz vollständig beschrieben wird, schau dir zuerst ein paar Live-Seiten an - eine Robotertransformations-Blaupause und ein Daten-Physikalisierungskonzept zeigen beide die Felder, die du von jedem der drei oben genannten Pfade zurückbekommst.

Für eine kompakte maschinenlesbare Zusammenfassung von allem oben hat llms.txt die Kurzversion. Für Menschen, die entscheiden, wo sie anfangen, ist die Antwort normalerweise: Wenn du dir nicht sicher bist, starte mit der Such-API - sie ist die geringste Verpflichtung und am schnellsten zu testen.