Trois façons d'accéder à Wikiprompt : jeu de données en masse, API de recherche et MCP

Trois façons d'accéder à Wikiprompt : jeu de données en masse, API de recherche et MCP

Wikiprompt compte désormais plus de 55 000 invites IA organisées derrière trois portes différentes, et choisir la mauvaise est le moyen le plus simple de perdre un après-midi. Si vous écrivez un scraper qui martèle /search en boucle pour reconstruire tout le catalogue localement, vous finirez par être limité en débit et vous aurez réinventé quelque chose que nous avons déjà construit pour vous. Si vous téléchargez l'intégralité du jeu de données juste pour répondre à une seule requête au moment de la demande dans un agent de chat, vous avez expédié 55 000 enregistrements pour répondre à une question qui n'en nécessitait que trois.

Le bon choix dépend entièrement de la forme de votre problème : avez-vous besoin de tout, avez-vous besoin d'une réponse à une seule question, ou avez-vous besoin d'un outil qu'un modèle de langage peut appeler de lui-même. Voici comment les trois chemins d'intégration correspondent à ces trois besoins.

Chemin 1 : le jeu de données en masse, quand vous avez besoin de tout le catalogue

Utilisez-le lorsque vous vous entraînez sur des données d'invites, construisez votre propre index de recherche, effectuez une analyse sur l'ensemble du corpus, ou miroitez le catalogue dans votre propre base de données. C'est l'option "télécharger une fois, posséder les données".

Commencez par le manifeste du jeu de données. Il renvoie du JSON avec total_prompts, les record_fields que vous obtiendrez, et le schéma de pagination, afin que vous puissiez vérifier la forme avant de tirer quoi que ce soit.

Les enregistrements réels se trouvent sur /dataset/prompts. La pagination est basée sur les clés : chaque réponse inclut une URL next, et vous continuez à la suivre jusqu'à ce que next revienne null. La taille de page par défaut est de 200 et peut aller jusqu'à 500 :

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

Une boucle de pagination minimale en Python ressemble à ceci :

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), "invites tirées")

Chaque enregistrement porte slug, url, title, description, content (le texte réel de l'invite), category, tags, media, model, des metadata structurées (type de média, ratio d'aspect, style, évaluation de qualité), author, original_source, et des horodatages. Pas de clé API, CORS est grand ouvert, et les réponses sont mises en cache en périphérie, donc un tirage complet est rapide et ne met aucune charge réelle sur nos serveurs.

Le compromis est la fraîcheur. Un tirage en masse est un instantané. Si vous avez besoin de l'état du catalogue il y a cinq minutes, c'est le mauvais outil, vous voulez l'un des deux suivants.

Chemin 2 : l'API de recherche, quand vous avez besoin de réponses ciblées

Utilisez-la lorsque votre intégration n'a besoin que d'une poignée d'invites par requête, par exemple un widget "invite du jour", un bot Slack qui répond "trouve-moi une invite de logo", ou une fonctionnalité qui affiche des invites pertinentes dans votre propre produit. Télécharger l'intégralité du jeu de données pour cela est une bande passante gaspillée et une maintenance gaspillée (vous devriez le re-synchroniser constamment).

Le point de terminaison est https://www.wikiprompt.org/api/search?q=VOTREQUETE, JSON simple, sans authentification. Une requête pour une invite de logo :

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

C'est une requête en direct sur le catalogue actuel, donc une invite publiée il y a une heure apparaît immédiatement, contrairement à un instantané de jeu de données que vous avez tiré la semaine dernière. C'est aussi économique des deux côtés : vous obtenez une poignée de correspondances au lieu d'analyser des milliers d'enregistrements côté client pour trouver les deux qui comptent. Si votre intégration est pilotée par les requêtes (un utilisateur tape quelque chose, vous avez besoin d'un résultat), c'est presque toujours le bon choix.

Chemin 3 : le serveur MCP, quand l'appelant est un agent IA

Utilisez-le lorsque Claude, ou tout autre agent compatible MCP, doit parcourir ou tirer de Wikiprompt dans le cadre d'une conversation, pas comme un travail backend que vous avez écrit et contrôlé. Le serveur MCP expose la découverte d'invites comme des outils qu'un agent décide d'appeler de lui-même, en pleine conversation, en fonction de ce que l'utilisateur a réellement demandé.

Pointez un client MCP vers https://mcp.wikiprompt.org/mcp (HTTP Streamable) et l'agent obtient des outils comme search_prompts, get_prompt, list_categories, get_featured, get_trending, et random_prompt, plus un modèle d'invite use_prompt(slug). Depuis la CLI :

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

Une fois connecté, un agent construisant une conception de personnage peut appeler search_prompts pour s'inspirer et tirer quelque chose comme ce brief de personnage voyageur nomade sans que vous écriviez une seule ligne de code d'intégration. Le jeu de données et l'API de recherche exigent tous deux que vous écriviez le code d'appel et décidiez quand appeler. MCP inverse cela : l'agent décide, au moment où il en a besoin, quel outil appeler et avec quels arguments. C'est tout l'intérêt de construire pour les agents plutôt que pour les scripts.

Choisir entre eux

Une règle approximative : jeu de données pour le volume, API de recherche pour les recherches ponctuelles depuis votre propre backend, MCP pour tout ce où un agent IA est celui qui décide quoi récupérer. Quelques cas concrets :

Ils ne sont pas mutuellement exclusifs. Un seul produit pourrait tirer le jeu de données en masse une fois par semaine pour alimenter sa propre fonctionnalité de recommandation, exposer une boîte de recherche en direct contre /api/search, et enregistrer séparément le serveur MCP pour que ses fonctionnalités IA puissent parcourir le catalogue actuel directement. Rien dans le choix de l'un ne vous verrouille hors des autres.

Quel que soit le chemin que vous utilisez, le contenu est agrégé à partir de publications publiques de vraies personnes, pas sous licence de leur part, donc jouez franc jeu : créditez wikiprompt.org et, par enregistrement, la original_source d'où l'invite provient réellement. Si vous voulez un aperçu plus proche de la façon dont un enregistrement est décrit en détail avant de toucher au code, parcourez d'abord quelques pages en direct, un plan d'ingénierie de transformation de robot et un concept de physicalisation de données montrent tous deux les champs que vous obtiendrez de l'un des trois chemins ci-dessus.

Pour un résumé compact lisible par machine de tout ce qui précède, llms.txt a la version courte. Pour les humains qui décident par où commencer, la réponse est généralement : si vous n'êtes pas sûr, commencez par l'API de recherche, c'est le moins d'engagement et le plus rapide à tester.