Every Catalog Wants to Be an MCP Server

written by Stefan Christoph

- 8 minutes read
TL;DR: AWS just shipped an open-source MCP server for the Registry of Open Data — 1,100+ datasets from 400+ organizations (NASA, NOAA, NIH, the Allen Institute), now discoverable by asking your AI assistant a plain-language question instead of clicking through a catalog. It’s a modest launch. But it’s the clearest example yet of a pattern I keep seeing: the interesting move is no longer wrapping the client in AI. It’s wrapping the catalog in MCP so any assistant can discover, explore, and sample it. Discovery is becoming a protocol.

I already live inside this pattern

My whole working setup is a constellation of MCP servers. When I want calendar context, customer data, a Slack thread, or an internal doc, I don’t open six tools; an assistant reaches through the relevant MCP server and brings it back into one conversation. I’ve written a multi-part series on MCP strategies [4] precisely because that mediation layer turned out to be the thing that made a pile of separate systems feel like one.

So when AWS launched an MCP server for the Registry of Open Data [3] (RODA), I recognized it immediately, not as a new product but as the same pattern escaping into a new place: a public data catalog.

The boring launch with the non-boring implication

Here’s what shipped, verified against the announcement [1]. RODA hosts over 1,100 datasets from more than 400 organizations — satellite imagery, life sciences, climate, genomics, hundreds of petabytes from the likes of NASA, NOAA, and NIH. The data was always open. The problem was never access; it was discovery. To go from a research question to the right dataset you had to search a catalog, find the S3 bucket, understand the file layout, and pull a few files to check fit. Manual, every time.

The RODA MCP server collapses that into a conversation. It exposes tools around three verbs:

  • Discover: “search for datasets to study ocean temperature” returns matching datasets with descriptions and licensing.
  • Explore: “get more details about the 1000 Genomes data” or “find similar datasets” surfaces full metadata and related resources.
  • Evaluate: “preview this dataset” shows the S3 bucket structure; “sample this file” reads a slice so you can check fit before committing.

You install it with one line (uvx awslabs.roda-mcp-server@latest) into Kiro or any MCP-compatible assistant, and it’s Apache-2.0 open source. That’s the whole thing. Small.

But look at the shape. AWS didn’t build a chatbot on top of RODA. It didn’t add an “AI search” button to the catalog website. It wrapped the catalog in a protocol so that whatever assistant you already use gains the ability to discover it. The intelligence isn’t in the catalog. It’s in the client you bring, and the catalog just made itself reachable.

Discovery is becoming a protocol

That’s the pattern worth naming: wrap the catalog, not the client.

For a decade the integration story was the opposite. If you had a data catalog, an internal wiki, a service registry, a documentation site, you’d build search into it, maybe bolt on a bespoke assistant, and every consumer had to come to your UI. N catalogs meant N different discovery experiences and N integrations.

MCP inverts that. The catalog implements one server; every AI client speaks the same protocol; discovery composes. A researcher’s assistant can, in a single conversation, discover a NOAA dataset via RODA, cross-reference it with something from another MCP-wrapped source, and never touch either product’s website. The “discovery layer” stops being a feature each catalog builds and becomes a protocol they all expose.

Once you see it, you see it everywhere it should happen next:

  • Internal data catalogs and lakehouses, discoverable by the team’s assistant instead of just the catalog UI.
  • Documentation sites and knowledge bases: “find me the doc that explains X” across sources.
  • Service registries and API catalogs, where an agent discovers the right internal API the way RODA discovers a dataset.

Every catalog is a discovery problem wearing a browsing UI. MCP is the standard answer to the discovery half.

Try it: 175 years of climate in one sentence

Enough theory. The fastest way to feel the shift is to point it at a real catalog. Add the server to your assistant (here, Kiro’s mcp.json):

{
  "mcpServers": {
    "roda": {
      "command": "uvx",
      "args": ["awslabs.roda-mcp-server@latest"],
      "env": { "FASTMCP_LOG_LEVEL": "ERROR" }
    }
  }
}

Now ask the kind of question a curious human actually asks — no bucket names, no S3 knowledge:

You: Find an open dataset with long-run daily temperature records for weather stations worldwide. You: What’s the license and coverage on that NOAA one? You: Preview its bucket layout and sample a file so I can see the columns.

Your assistant’s phrasing will vary, but it comes back with NOAA’s Global Historical Climatology Network – Daily: station-based daily max/min temperature, precipitation and snow, CC0 public domain, with some records more than 175 years old (one CSV per year, from 1763 to today).[5] It shows you the bucket structure and drops a sample of the columns straight into the chat. You went from a plain-English question to a previewed, license-checked, 260-year climate dataset, and you never learned a bucket name.

Here’s the part that makes the point. This is roughly the code you’d have written the old way just for that last step:

import boto3
from botocore import UNSIGNED
from botocore.config import Config

# ...but first you had to KNOW all of this:
#   - the bucket is "noaa-ghcn-pds"
#   - it lives in us-east-1
#   - it's public, so you access it UNSIGNED (no credentials)
#   - the files sit under csv/, csv.gz/ and parquet/ prefixes (NOAA has been migrating the layout)
s3 = boto3.client("s3", region_name="us-east-1",
                  config=Config(signature_version=UNSIGNED))

resp = s3.list_objects_v2(Bucket="noaa-ghcn-pds", MaxKeys=10)
for obj in resp["Contents"]:
    print(obj["Key"])

I ran exactly this against the public bucket. The first keys it returns:

csv.gz/1763.csv.gz
csv.gz/1764.csv.gz
csv.gz/1765.csv.gz
...

The 260-year record shows up literally as the first rows of a directory listing: 1763 onward. (The bucket also exposes csv/by_year/ for recent uncompressed years and a newer parquet/ layout; NOAA has been migrating it, which is exactly the kind of shifting detail you’d otherwise have to keep re-learning.)

Every comment in that snippet is a fact you had to acquire before the first useful line: the bucket name, the region, that it’s unsigned, that the layout is per-year (and, per NOAA’s own notice, mid-migration). None of it is hard; all of it is friction, paid again every time you meet a new catalog. Wrapping RODA as an MCP server moves that discovery into the assistant: the boto3 above is what a human writes once they’ve finished the manual archaeology; the MCP just does the archaeology for you and hands you the question.

That is the whole “every catalog wants to be an MCP server” idea in one example. The data was always open. What changed is that finding, licensing, and sampling it stopped being a research project and became a sentence.

The full runnable sample — this list_ghcn.py plus the mcp.json config — is in the companion code repo.[6]

Where I’d stay skeptical

I don’t want to oversell a one-line install. A few honest edges:

  • A discovery layer is only as good as its metadata. RODA works because its datasets are well-described. Point this pattern at a catalog of stale, thinly-documented entries and the assistant will confidently surface junk. The MCP server doesn’t fix bad metadata; it exposes it faster.
  • “Sample before you commit” is the underrated tool. The evaluate verb (preview the bucket, read a slice) is what stops this from being glorified search. Discovery without evaluation just relocates the manual fit-checking; keep that capability when you build your own.
  • Curation and governance don’t vanish. Making everything discoverable through one protocol raises the same questions internal search always did: who’s allowed to find what, and how do you keep the catalog from becoming a swamp. The protocol standardizes access; it doesn’t standardize good stewardship.

If you’re running this on AWS

If you have open-data or research workflows, the concrete win is immediate: uvx awslabs.roda-mcp-server@latest, ask your assistant a research question, and skip the catalog-spelunking. But the more useful takeaway is the template. If you own an internal catalog (a data catalog, a service registry, a docs corpus), the RODA server is a small, readable, open-source reference [2] for wrapping it in MCP so your teams discover it through the assistant they already use, instead of through yet another search box. The repo is on GitHub under awslabs; it’s a good afternoon read.

The launch is about open data. The pattern is about everything you have that’s currently hidden behind a browse-and-click UI.

What’s the catalog on your side of the fence that everyone knows exists but nobody can find their way through, and what would change if your assistant could discover it in one sentence?

Sources

Stefan Christoph

About the Author

Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.

This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.

Learn more →

❤️ Created with the support of AI (Kiro)

📝 Last updated: August 17, 2026 — Editorial polish for readability and voice