Three Ways to Access Wikiprompt: Bulk Dataset, Search API, and MCP

Three Ways to Access Wikiprompt: Bulk Dataset, Search API, and MCP

Wikiprompt now has over 55,000 curated AI prompts sitting behind three different doors, and picking the wrong one is the easiest way to waste an afternoon. If you write a scraper that hammers /search in a loop to rebuild the whole catalog locally, you will get rate-limited eventually and you will have reinvented something we already built for you. If you download the entire dataset just to answer one query at request time inside a chat agent, you have shipped 55,000 records to answer a question that needed three.

The right choice depends entirely on the shape of your problem: do you need everything, do you need one answer to one question, or do you need a tool that a language model can call on its own. Here is how the three integration paths map to those three needs.

Path 1: the bulk dataset, when you need the whole catalog

Use this when you are training on prompt data, building your own search index, running analysis across the corpus, or mirroring the catalog into your own database. It is the "download once, own the data" option.

Start at the dataset manifest. It returns JSON with total_prompts, the record_fields you'll get back, and the pagination scheme, so you can sanity-check the shape before you pull anything.

The actual records live at /dataset/prompts. Pagination is keyset-based: each response includes a next URL, and you keep following it until next comes back null. Page size defaults to 200 and goes up to 500:

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

A minimal pagination loop in Python looks like this:

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")

Each record carries slug, url, title, description, content (the actual prompt text), category, tags, media, model, structured metadata (media type, aspect ratio, style, quality assessment), author, original_source, and timestamps. No API key, CORS is wide open, and responses are edge-cached, so a full pull is fast and does not put any real load on our servers.

The tradeoff is freshness. A bulk pull is a snapshot. If you need the state of the catalog five minutes ago, this is the wrong tool, you want one of the next two.

Path 2: the search API, when you need targeted answers

Use this when your integration only ever needs a handful of prompts per request, for example a "prompt of the day" widget, a Slack bot that answers "find me a logo prompt," or a feature that surfaces relevant prompts inside your own product. Downloading the entire dataset for this is wasted bandwidth and wasted maintenance (you'd have to keep re-syncing it).

The endpoint is https://www.wikiprompt.org/api/search?q=YOURQUERY, plain JSON, no auth. A query for a logo prompt:

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

This is a live query against the current catalog, so a prompt published an hour ago shows up immediately, unlike a dataset snapshot you pulled last week. It is also cheap on both ends: you get back a handful of matches instead of parsing thousands of records client-side to find the two that matter. If your integration is request-driven (a user types something, you need a result), this is almost always the right fit.

Path 3: the MCP server, when the caller is an AI agent

Use this when Claude, or any other MCP-capable agent, needs to browse or pull from Wikiprompt as part of a conversation, not as a backend job you wrote and control. The MCP server exposes prompt discovery as tools an agent decides to call on its own, mid-conversation, based on what the user actually asked for.

Point an MCP client at https://mcp.wikiprompt.org/mcp (Streamable HTTP) and the agent gets tools like search_prompts, get_prompt, list_categories, get_featured, get_trending, and random_prompt, plus a use_prompt(slug) prompt template. From the CLI:

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

Once connected, an agent building a character design can call search_prompts for inspiration and pull back something like this nomadic traveler character brief without you writing a single line of integration code. The dataset and the search API both require you to write the calling code and decide when to call. MCP inverts that: the agent decides, at the moment it needs it, which tool to call and with what arguments. That is the entire point of building for agents instead of building for scripts.

Picking between them

A rough rule: dataset for bulk, search API for one-off lookups from your own backend, MCP for anything where an AI agent is the one deciding what to fetch. A few concrete cases:

They are not mutually exclusive. A single product could pull the bulk dataset once a week to power its own recommendation feature, expose a live search box against /api/search, and separately register the MCP server so its AI features can browse the current catalog directly. Nothing about picking one locks you out of the others.

Whichever path you use, the content is aggregated from real people's public posts, not licensed from them, so play fair: credit wikiprompt.org and, per record, the original_source the prompt actually came from. If you want a closer look at how a record is described in full before you touch code, browse a couple of live pages first, a robot transformation blueprint and a data physicalization concept both show the fields you'll get back from any of the three paths above.

For a compact machine-readable summary of everything above, llms.txt has the short version. For humans deciding where to start, the answer is usually: if you're not sure, start with the search API, it's the least commitment and the fastest to test.