Meta Data Mcp

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 itbrew install uv
# Linuxcurl -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-codeuv 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.

• Consent: if your MCP client supports elicitation, you'll get a yes/no prompt (default yes) before the PR is opened.
• What's shared: only the three generated files (spec, provider module, test stub) on a contribute/plugin-<id> branch. Your working tree is never touched.
• Opt out: set META_DATA_MCP_AUTO_CONTRIBUTE=0.
• Target repo: derived from your origin remote; override with META_DATA_MCP_CONTRIBUTE_REPO=owner/repo.
• Requires the gh CLI authenticated with push access. Without it, the branch is committed locally and the response tells you how to finish the PR.

Presentation layer (MCP Apps)

v2.0 adds a visual layer on top of every tool result. Hosts that support the MCP Apps extension (Claude Desktop, MCP Inspector, others) render bound tool results inline as interactive panels in a sandboxed iframe instead of as JSON text. Hosts that don't speak MCP Apps fall back to the same JSON they always got — the binding is purely additive.

Each MCP-Apps-aware tool declares its panel via _meta.ui.resourceUri on the tool description. The host fetches the ui:// resource (HTML + bundled JS, single payload, no external requests besides explicitly-whitelisted CDNs) and dispatches bidirectional postMessage events between the iframe and itself.

Shape primitives — ui://meta-data-mcp/shape/<name>/v1

Three reusable bundles cover the common payload contracts. Any tool whose response matches one of these shapes binds to the corresponding primitive automatically and gets a rich renderer for free.

Custom apps — ui://meta-data-mcp/app/<name>/v1

Some data shapes don't fit a generic primitive. v2.0 ships dedicated apps for them:

Building new apps

Adding a UI binding to a generated provider is now a one-line spec change:

tools:  - name: my-tool    description: ...    endpoint: /foo    response_shape: records   # ← binds to the shape primitive

See tools/specs/README.md for the full reference. Bundle-size budgets are enforced in CI (warn ≥ 100 KB, error ≥ 1 MB); the v2.0 bundles range from 14 KB (timeseries primitive) to 34 KB (vulnerability app), all comfortably inside the budget.

Citable answers

Every tool result carries a machine-readable citation manifest: exactly which upstream requests produced it. The transport kernel records each HTTP exchange during a tool call, and the result's first content block gains a _meta["meta-data-mcp/citations"] entry:

{  "sources": [    {      "provider": "eu-eurostat",      "title": "Eurostat",      "homepage": "https://ec.europa.eu/eurostat",      "license": "Eurostat data is reusable under CC BY 4.0; cite '© European Union, Eurostat'.",      "url": "https://ec.europa.eu/eurostat/api/dissemination/statistics/1.0/data/nama_10_gdp?format=JSON&lang=en",      "method": "GET",      "status": 200,      "fetched_at": "2026-07-09T14:02:11.482Z",      "cache_hit": false    }  ]}

This is what makes an LLM data answer auditable: the exact URL(s) — query parameters included — when they were fetched, whether they came from the transport cache, and the provider's license/attribution terms. Anyone can re-issue the URL and check the claim.

• Secrets never leak. Values of sensitive query parameters are replaced with REDACTED — an exact denylist (api_key, token, appid, …) plus conservative heuristics (*key, *token, *secret*, *signature*, …) that also cover presigned cloud-storage URLs and plugin-specific key params. Userinfo credentials in the URL itself (https://user:pass@host) are redacted too; parameter names are preserved so the URL stays reproducible with your own credentials. Headers never enter the manifest.
• Failed exchanges are cited too — a 4xx/5xx a handler recovered from, and the intermediate 429/5xx attempts the kernel's retry loop absorbed, are part of how the answer was produced; filter on status. (A tool call that errors out returns the SDK's isError result, which carries no manifest.)
• Honest timestamps. fetched_at is when the bytes were actually fetched: cache-served exchanges report the original fetch time with cache_hit: true, not the cache-read time.
• On by default. Set META_DATA_MCP_CITATIONS=0 to disable. Complements the opt-in tamper-evidence digest (META_DATA_MCP_PROVENANCE); both can coexist on the same result.

Bundled plugins (90)

This is what's inside the one server. You don't install these individually — they all come along.

Government / Civic

Statistics / Economics

Finance / Markets

Health & Life Sciences

Earth Science / Weather / Environment

Biodiversity / Space / Physics

Geo / Mapping / Knowledge

Agriculture / Trade

Security / Vulnerability

Transit / Aviation

Scholarly Literature

Culture / Books

News / Media

Networking / Internet

Legal

Optional environment variables

A few bundled plugins accept optional API keys for higher rate limits. Set these in your shell or in the Claude Desktop server config's env block:

Server runtime flags

Transports

run defaults to SSE (HTTP, port 8000) so you can connect from the MCP Inspector or remote clients. For Claude Desktop (which the setup command targets), the spawned process uses stdio:

uv run meta-data-mcp run                                  # SSE on 127.0.0.1:8000uv run meta-data-mcp run --transport stdio                # stdiouv run meta-data-mcp run --host 0.0.0.0 --port 3001       # SSE bound to all interfaces

Roadmap

Shipped

• Hierarchical discovery (v2.0): opendata_providers_find with ranked scoring replaces the originally-planned browse/list tools.
• Agent-driven generation (v2.1): opendata_plugins_draft + opendata_plugins_create let the model close coverage gaps autonomously. Hardened in v2.1.1 with input allowlists, path containment, and a post-generation AST validator (14 RCE/path-traversal/bypass paths closed).
• Self-hosted SSE deployment (v2.1): bearer-auth-protected, systemd-managed, reverse-proxied.
• Multi-language SDK (v2.2): Python embedded client (meta_data_mcp.sdk) and TypeScript/Node client (@meta-data-mcp/sdk) for discovery over MCP SSE.
• OAuth 2.0 (v2.3): Authorization Code + PKCE + Dynamic Client Registration. Works with Claude.ai (StreamableHTTP) and MCP Inspector. /.well-known/oauth-authorization-server, /.well-known/oauth-protected-resource, and /.well-known/openid-configuration all served.
• MCP registry provider (v2.3.4): mcp_registry_search and mcp_registry_list — discover other MCP servers from within meta-data-mcp. Listed on the official MCP registry and Smithery.

Still ahead

• Expand provider coverage beyond the current 90.

Credits

• Originally conceived by grll as opendata-mcp.
• Forked and reshaped around the single-server "meta-mcp" model.
• Built on Anthropic's open-source MCP spec.

License

MIT — see LICENSE.