Nourrissez votre agent IA avec Wikiprompt : serveur MCP + jeu de données ouvert

Alimentez votre agent IA avec Wikiprompt : serveur MCP + jeu de données ouvert

Si vous construisez un agent, la partie difficile est rarement la boucle de raisonnement. C'est donner au modèle quelque chose qui vaut la peine d'être raisonné. Un agent qui sait écrire du code mais n'a aucune idée de ce à quoi ressemble un bon prompt Midjourney, ou de quelle structure de prompt système fait réellement obéir un assistant de codage, manque toute une catégorie de connaissances ancrées. Wikiprompt existe pour combler cette lacune, et il y a désormais deux façons de l'intégrer à ce que vous construisez : un serveur MCP en direct que votre agent peut appeler à l'exécution, et un jeu de données en masse que vous pouvez indexer une fois et conserver localement.

Ils résolvent des problèmes différents, et la plupart des configurations sérieuses finissent par utiliser les deux.

Le serveur MCP : à un appel d'outil

Le serveur MCP à https://mcp.wikiprompt.org/mcp est un point de terminaison HTTP Streamable, sans clé API requise pour les lectures. Pointez Claude, ou tout client compatible MCP, vers lui et votre agent gagne des outils comme search_prompts, get_prompt, list_categories, get_featured, get_trending, random_prompt, et prompts_by_author, en plus du catalogue complet de plus de 55 000 prompts soigneusement sélectionnés.

L'ajouter à Claude Code est une seule ligne :

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

Une fois connecté, l'agent n'a pas besoin que vous colliez un prompt dans la conversation. Il peut décider, en pleine tâche, qu'il veut un exemple. Disons qu'un utilisateur demande à votre assistant "donne-moi une structure de prompt système pour un bot de support client." Au lieu d'inventer un modèle plausible, l'agent appelle search_prompts avec quelque chose comme model=claude prompt_type=system-prompt, récupère de vrais résultats sélectionnés par des humains avec des métadonnées de qualité attachées, et peut synthétiser une réponse qui cite réellement d'où vient le modèle. C'est une réponse matériellement différente de celle construite uniquement sur l'intuition des données d'entraînement, et c'est le type d'ancrage qui rend les recommandations d'un agent défendables plutôt que simplement plausibles.

Cela compte encore plus pour les agents de génération d'images et de vidéos. Si votre agent enveloppe GPT Image, Midjourney, Seedance, Veo, Kling, ou Nano Banana, il peut appeler search_prompts filtré par modèle et style, récupérer des prompts avec des metadata structurées (ratio d'aspect, balises de style, évaluation de qualité), et donner à l'utilisateur un point de départ qui a été vérifié plutôt qu'inventé sur le moment. Regardez ce prompt de transformation de personnage arachnide futuriste ou ce plan d'ingénierie titanesque d'un robot transformable : ce sont exactement le genre de prompts à haute structure et haute spécificité qu'il est facile de décrire mal de mémoire et facile de réutiliser correctement quand on peut réellement les récupérer.

Il y a aussi submit_prompt, qui permet à un agent d'écrire en retour dans le catalogue (clé API requise pour celui-là). Si votre agent génère quelque chose de vraiment bon, dans un outil de flux de travail ou un pipeline créatif, il peut le contribuer au commun au lieu de le perdre dans un journal de chat.

Le jeu de données : pour quand vous le voulez hors ligne

Le serveur MCP est excellent pour les recherches à la demande, mais c'est un appel réseau en direct, et parfois vous voulez tout le catalogue dans votre propre magasin vectoriel, interrogeable avec vos propres plongements, joint à vos propres données. C'est à ça que sert le jeu de données.

Frappez le manifeste d'abord :

curl "https://www.wikiprompt.org/dataset"

Il renvoie total_prompts, les record_fields que vous obtiendrez, et le schéma de pagination. Les enregistrements réels se trouvent à /dataset/prompts, paginés avec un curseur de jeu de clés, jusqu'à 500 par page :

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

Chaque réponse inclut une URL next. Suivez-la jusqu'à ce que next revienne null et vous avez les 55 000+ complets, y compris slug, url, title, description, content (le texte réel du prompt que vous plongeriez), category, tags, media, model, metadata structurées, author, et original_source. Une boucle de pagination minimale :

import requests

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

records = []

while url:

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

records.extend(resp["records"])

url = resp.get("next")

print(len(records), "prompts collectés")

Pas de clé API, CORS activé, mis en cache en périphérie, donc vous pouvez l'exécuter depuis un outil basé sur navigateur ou un travail CI sans demander la permission d'abord. Découpez content plus title et description dans votre pipeline de plongement, gardez category, tags, et metadata comme champs filtrables, et vous avez une base de connaissances prête pour RAG qu'un agent peut interroger localement, sans dépendance à notre disponibilité.

C'est aussi le meilleur chemin si le travail de votre agent est analytique plutôt que conversationnel : construire un classement de quel modèle apparaît le plus dans les prompts de haute qualité, regrouper les prompts par technique, ou entraîner un re-rank de récupération sur les signaux de qualité metadata.assessment. Le jeu de données vous donne la matière première ; ce que vous construisez par-dessus vous appartient.

Les assembler

Un modèle qui fonctionne bien en pratique : chargez en masse le jeu de données dans votre magasin vectoriel comme couche de connaissances de base, et gardez le serveur MCP branché pour la fraîcheur. De nouveaux prompts arrivent sur wikiprompt en continu, et get_recent ou get_trending via MCP fera remonter des choses que votre dernier instantané du jeu de données n'a pas encore. Le jeu de données vous donne la profondeur et la fiabilité hors ligne ; le serveur MCP vous donne le dernier kilomètre.

Un exemple qui vaut la peine d'être vérifié directement via l'un ou l'autre chemin est ce prompt d'image de physicalisation de données, une bonne illustration de combien de structure un prompt bien sélectionné porte par rapport à une description d'une ligne, et exactement le genre de détail qui vaut la peine d'être récupéré plutôt que reconstruit à partir d'une supposition de modèle.

Quelle que soit la façon dont vous vous branchez, attribuez ce que vous utilisez. Chaque enregistrement porte son original_source, et les personnes qui ont écrit ces prompts sont celles qui ont fait le travail créatif réel. Citez wikiprompt.org comme agrégateur et liez en retour au post original quand vous le pouvez.

Si vous voulez la version en texte brut pour un scan rapide sans analyse JSON, llms.txt donne à n'importe quel agent un aperçu de toute la surface lisible par machine du site en un seul fichier. Et si la recherche est tout ce dont votre agent a besoin, sans s'engager ni sur MCP ni sur le jeu de données complet, l'API de recherche est un simple GET JSON qui n'a besoin que d'une chaîne de requête.