Meta Data MCP Server

meta-data-mcp

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

meta-data-mcp is one MCP server — not many. Under the hood it bundles 76 plugins, each wrapping a different open-data API. The plugins are an implementation detail; from your LLM's perspective there is one server, one set of tools, 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 + every plugin's tools available under it.

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 eight server-level tools below. They make routing transparent: the LLM uses them to find (or create) the right plugin without you telling it which tool to call.
2. Plugin tools — ~330 tools coming from the 76 bundled plugins. They are merged into the same namespace at startup. 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 picks the matching plugin's tool and answers — done.
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 and opendata.providers.describe; you don't need to memorize them.

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.

Bundled plugins (76)

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

Transit / Aviation

Scholarly Literature

Culture / Books

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:8000
uv run meta-data-mcp run --transport stdio                # stdio
uv 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 76.
• MCP Apps presentation layer — shape primitives (timeseries, geo, records) for inline data visualization in supporting hosts.

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.