Your agent can now search our catalogue: introducing the Mozilla Data Collective MCP server

Until recently, dataset discovery meant a person at a computer searching the internet using a browser. You had to open a catalogue, type your search terms into a search box, review a datasheet, and then decide if that's the dataset you needed. With the rise of the agentic web - where AI agents perform tasks on behalf of the person at the keyboard - many data and machine learning practitioners are delegating the time-consuming task of finding datasets to their LLMs.

Dataset catalogues - like MDC - now need to be both human-readable and machine-readable - otherwise you won't be able to offload dataset discovery to your agent. That's why we've built a Mozilla Data Collective MCP server. It's read-only and anonymous, and it lets any MCP-speaking client search the Mozilla Data Collective catalogue directly - so you can do other things while your agents finds the right data for your project.

What's an MCP server?

The Model Context Protocol is a specification for how an LLM client discovers and calls capabilities it didn't ship with. An MCP server advertises a set of tools — each with a name, a natural-language description, and a JSON Schema for its arguments — and the client hands that advertisement to the model as part of its context. The model decides, unprompted, whether a given user request warrants calling one. The model reads your tool descriptions similarly to the way a developer reads API docs, forms an argument object, calls the tool, and grounds its answer in the results that are returned.

The better the MCP server, the better the answers your LLM client will be able to provide.

For example, a person asking "find me conversational Swahili audio I can fine-tune on" doesn't want a list of links to evaluate; they want an agent that searches, compares licences, and tells them which two are actually usable. For that agent to be trustworthy, it needs to be working from a grounded, deterministic, contemporary, accurate data source, not from data it was fed on during training that might now be out of date. That is, MCP servers can use live data to extend the capability of the LLM.

What the MDC MCP server does, and how to install it

The MDC MCP server exposes three tools.

The search/fetch naming and result shapes follow OpenAI's search/fetch connector convention, which ChatGPT's deep research mode requires and other clients such as Claude Code happily consume. While standards in this space are still in flux, we're trying to align with those that have broad adoption. search runs the same hybrid lexical-plus-semantic pipeline as the MDC web platform's own search box — so a descriptive phrase retrieves far better than a bare keyword. For example "multi-speaker Chinese conversational audio" will return better-matched datasets than a search term of "Chinese".

The MCP server only returns a list of dataset URLs. You cannot download datasets via the MCP server. In order to to that you must visit the dataset page in the browser, or use our API/Python SDK.

We're published to the official MCP registry as com.mozilladatacollective/datasets, so clients that search the registry can find us without being told the URL.

To add it to Claude Code:

claude mcp add --transport http mdc https://mozilladatacollective.com/api/mcp

For Cursor and other JSON-configured clients:

{
  "mcpServers": {
    "mozilla-data-collective": {
      "url": "https://mozilladatacollective.com/api/mcp"
    }
  }
}

For Claude.ai, it's Settings → Connectors → Add custom connector.

There are no credentials to configure, because there is nothing to authorise: the server is the MCP equivalent of our public /datasets pages, not of our authenticated REST API. It cannot download data, read private datasets, or make a purchase. Terms acceptance, payment and downloading all stay on the dataset's web page, where a human can see what they're agreeing to.

What it looks like in use

The intended loop is: search with the user's need phrased naturally, call list_filters if the user was specific, fetch the promising ones, hand over the URL.

Asked "I'm training a Swahili ASR model — is there anything here I could use?", a connected model calls search without being told to.

Raw, that's:

curl -X POST https://mozilladatacollective.com/api/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0", "id": 1, "method": "tools/call",
    "params": {
      "name": "search",
      "arguments": {
        "query": "conversational Swahili audio for ASR fine-tuning",
        "limit": 5
      }
    }
  }'

which comes back as an SSE frame wrapping the tool result:

event: message
data: {"result":{"content":[{"type":"text","text":"{\"total\":100,\"results\":[
  {\"id\":\"...\",\"title\":\"Common Voice Scripted Speech 27.0 - Swahili — ...\",
   \"url\":\"https://mozilladatacollective.com/datasets/...?utm_source=mcp&utm_medium=referral&utm_campaign=mcp_search\"},
  {\"id\":\"...\",\"title\":\"Read Speech in Kenyan Swahili (6h) — ...\"}, ...]}"}]}}

Good results: Common Voice Swahili, and dataset that has six hours of prompted Kenyan Swahili read speech. The model summarises those, the user asks "tell me more about the second one, can I use it commercially?", and it calls fetch — which returns metadata carrying licenseAbbreviation, organisation, sizeBytes and pricing, so it can quote the licence rather than infer it.

Limitations we're aware of

This is our first release of the MDC MCP server, and so it has some known limitations.

Our filter facets are not clean enough for exact matching.

• The format facet is free text drawn from what contributors typed, and list_filters currently returns 115 distinct values for it. Forty-three of them contain "WAV". Filtering format: ["WAV"] returns 19 datasets; filtering format: ["WAV, TSV"] returns 52; ["wav"] returns exactly one. There is no value that means "audio in WAV". A model doing the sensible thing — reading list_filters, picking WAV — silently misses most of the WAV corpora we hold.
• Licences have a similar limitation: MDC DLA 1.0, MDC DLA-1.0 and MDC-DLA 1.0 are three spellings of one licence. Swahili is spread across sw, swa, swb and swc. Normalising these facets matters more than anything else on this list, because the tool descriptions confidently instruct the model to match them exactly.
• We are planning future work to normalise our licenses and formats and we expect this feature to improve over time.

Filters can make results worse. Searching for Swahili ASR data unfiltered returns Common Voice Swahili and Kenyan read speech. Adding license: ["CC0-1.0"], format: ["WAV"] returns three speaker-verification corpora with no Swahili in them — narrower, exactly matched, and wrong. Consider filtering only if your original natural language request returns a large number of dataset results.

Invented values fail silently. locale: ["swahili"] and license: ["CC-BY"] both return zero results and no explanation. The model cannot distinguish "we hold nothing" from "you guessed the vocabulary wrong" — and a plausible "nothing found" is a much harder failure to notice than an error. You will need to pay attention to specific ISO-639 language codes (such as sw for Kiswahili).

Per-IP rate limits aggregate across a provider's users. We rate limit our platform to prevent denial of service (DoS) attacks. But hosted LLM providers funnel enormous numbers of end users through a handful of egress IPs, so those limits are shared in a way per-user limits wouldn't be. We're still monitoring how rate limiting impacts the developer experience and may adjust these if they are too restrictive.

We'd love your feedback to improve the MCP server

The next steps we take in supporting agentic use of the Mozilla Data Collective platform will be shaped by your feedback. We'd love to learn more about how you're using the MCP server: what functionality helps you find the data you need? What's missing? What should we build next? Reach us at [email protected].