meta-data-mcp

A single MCP server that transparently routes user requests to 90 open-data sources.

meta-data-mcp is one MCP server — not many. Under the hood it bundles 90 plugins, each wrapping a different open-data API. The plugins are an implementation detail; from your LLM's perspective there is one server and one place to ask "where can I find data about X?"

You install one server. You get all the data, discoverable through built-in routing tools.

Why "meta"?

Finding open data isn't the hard part — there's an absurd amount of it available. The hard part is finding the right dataset when you need it. meta-data-mcp makes that automatic:

• The LLM calls opendata_providers_find ("FX rates", "court rulings", "earthquakes near Lisbon") and the server routes the query against an internal registry of every bundled plugin.
• The LLM then calls the matching tool directly. No setup step in between, no separate servers, no per-provider install rituals.

This project was forked from opendata-mcp and reshaped around the single-server idea once the catalogue passed a few dozen plugins.

Installation

You'll need uv (a Python package manager).

# macOS — install uv via Homebrew so MCP clients can find it
brew install uv

# Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows (PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Then register the server with every MCP client installed on your machine:

uv run meta-data-mcp setup

The command auto-detects which MCP clients you have installed and adds one meta-data-mcp entry under mcpServers in each. Supported clients:

Each existing config is backed up to <file>.bak before writing. Restart the affected client(s) and you'll see one new server with discovery tools available immediately; plugin tools can then be activated on demand.

Inspect what's detected / configured on your machine:

uv run meta-data-mcp clients

Target a single client (or write to every supported client regardless of detection):

uv run meta-data-mcp setup --client claude-code
uv run meta-data-mcp setup --client all

If you want to see the JSON snippet without touching any config file (e.g. to paste into a client we don't support yet):

uv run meta-data-mcp setup --print-json

When META_DATA_MCP_AUTH_TOKEN is set, --print-json also surfaces the SSE-client snippet (with the real token) to stderr so you can wire a remote client.

Hosting meta-data-mcp as a remote SSE server

For deploying behind your own domain with bearer-token authentication, see docs/hosting.md. It covers systemd, Caddy/nginx TLS termination, token rotation, and the threat model.

CLI

There is one server, so the CLI takes no "provider" argument. Every command operates on the one meta-data-mcp server.

The list command exists for transparency about what's bundled — plugins are not separately installable, runnable, or addressable. They are loaded automatically when the server starts.

Server tools (what the LLM calls)

Once meta-data-mcp is running, the LLM has access to two layers of tools — and you don't need to mention either to the user:

1. Meta tools — the 13 server-level tools below. They make routing transparent: the LLM uses them to find, activate, and (if needed) create the right plugin without you telling it which tool to call.
2. Plugin tools — ~330 tools coming from the 90 bundled plugins. In the default discovery-only mode they are activated per provider at runtime (or preloaded via META_DATA_MCP_PRELOAD). The LLM picks one after consulting the meta tools.

Meta tools

The autonomous discovery flow

The reason this server is called "meta" is that it routes data requests on the user's behalf — including by creating the route when one doesn't exist yet. The full flow:

1. User asks for data, e.g. "show me the most recent published CVEs."
2. LLM calls opendata_providers_find with the query (cve, vulnerability, …).
3. If the registry has a match: the LLM activates the matching provider (opendata_providers_activate, or activate_top in find) and then calls the plugin tool.
4. If the registry has no match: the response includes no_match: true and a next_step field that explains the autonomous creation path. The LLM:
   1. Tells the user it's about to add coverage for this data source.
   2. Web-searches for an open API that exposes the requested data (e.g. the NVD or CIRCL CVE API).
   3. Calls opendata_plugins_draft with the API's id, base URL, and structured tool definitions. The server validates the inputs (id casing, path-placeholder consistency, parameter types) and returns a YAML string.
   4. Passes that YAML to opendata_plugins_create. The server materializes the plugin module + tests, imports the module, registers a ProviderEntry in the in-memory dynamic registry, and merges the new tools into the running server's tool list.
   5. Calls the newly-available tool to answer the user's original question.
5. User gets their answer — and the plugin remains available for the rest of the session.

The materialized plugin lives on disk (meta_data_mcp/providers/{id}.py + tests/providers/test_{id}.py); contributors can clean it up, add it to meta_data_mcp/registry.py as a static entry, and open a PR so it becomes part of every shipped install.

Plugin tools

Every bundled plugin contributes its own tools under the one server. Their names are unique kebab-case identifiers, often using a provider-specific prefix (e.g. usgs-eq-feed-significant-week, frankfurter-latest, wikipedia-fetch-summary). The LLM discovers them through opendata_providers_find/opendata_providers_describe, activates the provider when needed, and can inspect session state with opendata_providers_list_active.

Auto-contribution of created plugins

When opendata_plugins_create builds a new plugin, meta-data-mcp opens a pull request contributing it back to the project so others can use it — the catalogue grows from real usage.