Meta MCP Server

Connect Meta to Claude, Cursor or any other MCP client and it stops being a tab you switch to. Query 100+ open data APIs — government, science, finance, environment, and more. The meta mcp server is what makes that connection.

What the server does

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?"

• 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

Installation

Setup follows the usual MCP pattern — install or clone the server, register it in your client's configuration file, restart the client.

Available tools

The toolset is worth reading before you wire it up, because it tells you what the integration is really for:

• opendata_providers_find — Free-text search over the plugin registry. Returns ranked matches. When nothing matches the response carries a no_match: true flag and a next_step
• opendata_explain_choice — Show the scoring breakdown for a search (useful for debugging routing decisions)
• opendata_domains_list — Enumerate the controlled domain vocabulary (health, legal, finance, earth-science, …)
• opendata_regions_list — Enumerate the controlled region vocabulary (us, eu, uk, global, …)
• opendata_providers_describe — Full metadata for one plugin by id — title, description, domains, regions, keywords, homepage, required env vars
• opendata_providers_list — Paginated dump of the whole registry
• opendata_providers_activate — Activate one provider so its tools become callable in this session
• opendata_providers_deactivate — Remove an activated provider's tools from the current session catalog
• opendata_providers_list_active — List currently active providers and the tool names each contributes
• opendata_health_snapshot — Return per-provider health scores used by discovery health badges and routing context
• opendata_plugins_draft — Build a validated plugin YAML spec from structured inputs. Takes id, base_url, tool definitions (name, endpoint, params), and registry metadata
• opendata_plugins_create — Autonomously create a new plugin. Takes a YAML spec (typically produced by opendata_plugins_draft), runs the generator, imports the new module

Credentials and setup notes

Configuration is passed through the environment: META_DATA_MCP_AUTH_TOKEN. Treat anything key-shaped as a real credential — scope it to the minimum the server needs, and rotate it if it ever lands in a shared config.

Worth knowing first

• It runs with your machine's permissions. That is convenient and also the reason to think about what you point it at before you approve a tool call.
• With 13 tools registered it takes up a noticeable share of the context window; turn it off in projects that never touch Meta.
• Missing credentials fail quietly in some clients — if no tools show up, check the environment block first.
• Keep per-call confirmation enabled while you learn its behaviour; it is the cheapest safeguard you have.

Where it fits

Plenty of AI and media services servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. Meta's toolset — opendata_providers_find, opendata_explain_choice, opendata_domains_list and 10 more — is a fair guide to whether it matches your workflow. It is maintained by derekslinz; worth a glance at recent repository activity before you build anything load-bearing on it.

We check each listing at SyncDev against the project's documentation before it goes live — if something here drifts out of date, it is a bug worth reporting.