meta-data-mcp is a single MCP server that routes requests to 90+ open-data sources via a unified discovery and activation system (~330 plugin tools across 13 domains: government, economics, finance, health, earth science, biodiversity, security, transit, scholarly literature, culture, news, and networking).
Discover & Explore Data Sources
Free-text search across providers with optional domain/region filters (opendata_providers_find)
List all providers, domains, and regions (opendata_providers_list, opendata_domains_list, opendata_regions_list)
Get detailed metadata for a specific provider (opendata_providers_describe)
Understand ranking decisions via scoring breakdowns (opendata_explain_choice)
Activate & Use Providers
Load a provider's tools into the current session on demand (opendata_providers_activate / opendata_providers_deactivate)
Inspect which providers and tools are currently active (opendata_providers_list_active)
Proxy-call activated tools in environments where dynamic invocation isn't supported (opendata_tool_call)
Autonomously Create New Plugins
When no existing provider matches, draft a validated YAML plugin spec (opendata_plugins_draft) and materialize it into the live registry instantly (opendata_plugins_create)
Health & Observability
Check real-time health scores (0.0–1.0) reflecting errors, rate-limits, and network failures (opendata_health_snapshot)
All results include a citation manifest (upstream URLs, HTTP status, fetch timestamps, licenses) with secrets redacted, plus optional SHA-256 provenance digests
Rich Visual Output
Results render as interactive panels on supporting clients: line charts (time-series), Leaflet maps (geo features), faceted tables (records), and specialized apps for vulnerability data, entity graphs, trade flows, and more
Provides tools for fetching summaries from Wikipedia, enabling access to Wikipedia content programmatically.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@meta-data-mcp find earthquakes near Lisbon"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.
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.
Related MCP server: ReefAPI MCP
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 setupThe command auto-detects which MCP clients you have installed and adds one meta-data-mcp entry under mcpServers in each. Supported clients:
Client | Config file |
Claude Desktop |
|
Claude Code |
|
Cursor |
|
Windsurf |
|
Gemini CLI |
|
LM Studio |
|
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 clientsTarget 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 allIf 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-jsonWhen 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.
meta-data-mcp as a remote SSE serverFor 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.
There is one server, so the CLI takes no "provider" argument. Every command operates on the one meta-data-mcp server.
Command | What it does |
| Run the server (default SSE; pass |
| Register the server in detected MCP client configs (or one target via |
| Unregister the server from detected MCP client configs (or one target via |
| Detect and remove legacy multi-server entries ( |
| Launch mcp-inspector against the server. |
| Informational: list the internal plugins bundled in this server. |
| Informational: show server overview. Pass |
| Print the package version. |
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.
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:
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.
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.
Tool | Purpose |
| Free-text search over the plugin registry. Returns ranked matches. When nothing matches the response carries a |
| Show the scoring breakdown for a search (useful for debugging routing decisions). |
| Enumerate the controlled domain vocabulary ( |
| Enumerate the controlled region vocabulary ( |
| Full metadata for one plugin by id — title, description, domains, regions, keywords, homepage, required env vars. |
| Paginated dump of the whole registry. |
| Activate one provider so its tools become callable in this session. |
| Remove an activated provider's tools from the current session catalog. |
| List currently active providers and the tool names each contributes. |
| Return per-provider health scores used by discovery health badges and routing context. |
| Build a validated plugin YAML spec from structured inputs. Takes id, base_url, tool definitions (name, endpoint, params), and registry metadata. Validates id/tool-name casing, path-placeholder/param consistency, and parameter types, then emits a YAML string ready to feed into |
| Autonomously create a new plugin. Takes a YAML spec (typically produced by |
| Proxy-call an activated plugin tool by name for environments that cannot directly invoke dynamically added tools. |
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:
User asks for data, e.g. "show me the most recent published CVEs."
LLM calls opendata_providers_find with the query (cve, vulnerability, …).
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.
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:
Tells the user it's about to add coverage for this data source.
Web-searches for an open API that exposes the requested data (e.g. the NVD or CIRCL CVE API).
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.
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.
Calls the newly-available tool to answer the user's original question.
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.
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.
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.
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.
ui://meta-data-mcp/shape/<name>/v1Three 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.
Shape | Renders | Payload contract |
| Line chart + auto-computed profile (min/max/mean/stddev/gap-count) via Plotly. |
|
| Leaflet map + marker cluster (with density layer for high-cardinality outputs). | `{features: GeoJSON |
| Faceted, sortable, paginated HTML table + per-column auto-profile (type inference, top-k, null rate, range). |
|
ui://meta-data-mcp/app/<name>/v1Some data shapes don't fit a generic primitive. v2.0 ships dedicated apps for them:
App | Drives | Visualization |
|
| Faceted plugin browser with live health badges. |
|
| CVSS radar + severity heatmap + exploitation-probability gauge. |
|
| Force-directed graph (D3) with co-authorship overlay. |
|
| Reporter → commodity → partner Sankey + commodity treemap. |
|
| Volume + tone timeline with country-pair chord diagram. |
|
| Force-directed ASN peering/upstream/downstream graph. |
|
| WebGL 3D structure viewer (3Dmol.js, cartoon for proteins, stick+sphere for ligands). |
|
| Lazy-loaded CSS-grid image gallery + provenance detail panel. |
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 primitiveSee 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.
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.
This is what's inside the one server. You don't install these individually — they all come along.
Plugin | Source | Description |
| Australian Government Open Data | CKAN catalog at data.gov.au |
| Canada Open Data | CKAN catalog at open.canada.ca |
| opendata.swiss | Swiss federal open-data catalog (CKAN) |
| GovData Germany | Germany's federal open-data catalog (CKAN) |
| data.gouv.fr | French government open data platform |
| Tweede Kamer | Dutch Parliament open data |
| Singapore Open Data | data.gov.sg datasets and collections |
| data.gov.uk | UK government CKAN catalog |
| Town of Cary Open Data | Town of Cary, NC open data via Socrata — public safety, transportation, utilities, parks |
| Data.gov | US federal government open datasets |
| City of Fayetteville Open Data | City of Fayetteville, NC open data via Socrata — public safety, infrastructure, community services |
| City of Raleigh Open Data | City of Raleigh open data via Socrata — public safety, infrastructure, parks, planning |
Plugin | Source | Description |
| Eurostat | European Union statistics |
| International Monetary Fund | IMF SDMX 2.1 statistical data |
| FAOSTAT | UN food and agriculture statistics — production, prices, trade, land use, emissions |
| DBnomics | Global economic data aggregator (IMF, World Bank, etc.) |
| OECD | OECD economic & social statistics (SDMX) |
| World Bank | Development indicators by country |
| Statistics Netherlands (CBS) | Dutch statistical datasets (OData v2/v3) |
| UK ONS | UK Office for National Statistics |
Plugin | Source | Description |
| European Central Bank | ECB data portal (SDMX) — FX, monetary, banking |
| CoinGecko | Cryptocurrency market data |
| Frankfurter | ECB reference FX rates (key-less) |
| SEC EDGAR | Public company filings, XBRL financials |
| US Treasury Fiscal Data | Federal debt, daily Treasury statement, FX rates |
Plugin | Source | Description |
| ChEMBL | EMBL-EBI molecule and bioactivity database |
| disease.sh | COVID-19, influenza, vaccine aggregator |
| NCBI PubChem | Chemical compounds and substances |
| RCSB PDB | 3D protein and macromolecular structures |
| WHO GHO | WHO Global Health Observatory (OData) |
| US CDC | CDC open data via Socrata |
| ClinicalTrials.gov | NIH/NLM clinical trials registry v2 |
| openFDA | FDA adverse events, recalls, labels |
| HealthData.gov | HHS open health data via Socrata — outcomes, insurance, demographics, public health |
Plugin | Source | Description |
| Copernicus (EU) | European Earth observation and climate datasets |
| Open-Meteo | Weather forecast + historical + air quality |
| OpenAQ | Global air-quality measurements from reference monitors and sensors |
| NC DEQ Environmental GIS | NC Dept. of Environmental Quality ArcGIS Hub — permits, air/water quality, hazardous waste |
| NOAA NCEI | Climate data access services (key-less) |
| NOAA Tides & Currents | Water levels, tides, currents |
| USGS Earthquakes | Real-time and historical seismic events |
Plugin | Source | Description |
| CERN Open Data | Particle physics datasets and software |
| GBIF | Global biodiversity occurrence records |
| iNaturalist | Citizen-science species observations |
| OpenSky Network | Live ADS-B flight tracking |
| Le Systeme Solaire API | Open solar-system object and body metadata |
| NASA | APOD, Near Earth Objects, Mars rover photos |
Plugin | Source | Description |
| MCP Server Registry | Official MCP server registry — search and list published MCP servers |
| OSM Nominatim | Geocoding / reverse-geocoding (1 req/sec) |
| OSM Overpass | Query OpenStreetMap with Overpass QL |
| REST Countries | Country reference data — borders, capitals, currencies, languages, populations |
| Wikidata | Structured knowledge graph + SPARQL |
| Wikipedia | Article summaries, related, page views |
| ArcGIS REST API | Fetch public ArcGIS item metadata by ID — layers, maps, services, files |
| US Census Geocoder | Address ⇄ coordinates ⇄ geographies |
| NC OneMap | NC's authoritative GIS clearinghouse via ArcGIS REST — statewide geographic layers |
Plugin | Source | Description |
| UN Comtrade | International merchandise and services trade statistics |
Plugin | Source | Description |
| ENISA EUVD | Latest, exploited, critical, and filtered EU vulnerability search |
| CIRCL CVE Search | Recent CVEs, CVE details, and vendor/product browsing |
| crt.sh | Certificate transparency search for domains and certificates |
| FIRST.org EPSS | Exploit prediction scores and percentile ranks for CVEs |
| NVD CVE Database | NIST CVE records, filters, and change history |
| OpenSanctions | Sanctions, PEP, debarment, and related risk datasets |
| OSV.dev | Open source vulnerability advisories across ecosystems |
| Pwned Passwords | Anonymous breached-password SHA-1 prefix lookups |
| SSL Labs | Public TLS configuration and endpoint analysis |
| CISA KEV | Known Exploited Vulnerabilities catalog with remediation deadlines |
Plugin | Source | Description |
| Swiss Federal Railways | Swiss train disruptions and service data |
| Transitous | Worldwide transit journey planning — travel times, transfers, itineraries (MOTIS over open GTFS) |
| Deutsche Bahn | German railway open data |
| NDOV Loket | Dutch public transport data |
| OVapi | Live Dutch transit — real-time departures, vehicle positions, GTFS/GTFS-RT feeds |
| FAA NAS Status | US airspace status, delays, ground stops (XML) |
| NOAA Aviation Weather | METAR, TAF, and station weather data |
Plugin | Source | Description |
| arXiv | Preprint metadata (Atom XML) |
| Crossref | DOI metadata, citations, journals |
| DOAJ | Open-access journal and article search |
| Europe PMC | Biomedical literature + fulltext XML |
| OpenAlex | Open scholarly metadata |
Plugin | Source | Description |
| Met Museum | Met Museum Open Access (CC0) |
| Open Library | Books, authors, works (Internet Archive) |
| UNESCO World Heritage Sites | Natural, cultural & mixed World Heritage Sites |
Plugin | Source | Description |
| GDELT 2.0 | Global news, event, and tone monitoring across 100+ languages |
| Hacker News API | Public stories, comments, jobs, and user profiles |
Plugin | Source | Description |
| BGPView | BGP routing data — ASN info, prefixes, peers (key-less) |
| RIPE NCC RIPEstat | Production-grade BGP data (key-less) |
Plugin | Source | Description |
| Dutch Rechtspraak | Dutch court rulings and case law (ECLI) |
| UK legislation.gov.uk | UK Acts, statutory instruments (XML/Atom) |
| CourtListener | US court opinions, dockets, judges (Free Law Project) |
| US Federal Register | Daily rules, notices, executive orders |
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:
Variable | Plugin | Purpose |
|
| Anonymous access works at low volumes |
|
| Raises NVD API rate limits |
| all | Your email, used in User-Agent for polite-pool APIs (Crossref, OpenAlex, OSM, SEC EDGAR). Defaults to |
|
| Enables authenticated OpenAQ API access |
|
| Enables authenticated OpenSanctions API access |
|
| Enables higher-tier UN Comtrade API access |
Variable | Purpose |
| Comma-separated plugin ids to activate at startup, or |
| When set on the SSE transport, requires |
| Enable OAuth 2.0 Authorization Code + PKCE. Set to the server's public base URL (e.g. |
| Maximum number of registered OAuth clients kept in memory. Default |
| OAuth access-token lifetime in seconds. Default |
| Citation manifest on tool results (see Citable answers). Default on; set to |
| Truthy ( |
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 interfacesHierarchical 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.
Expand provider coverage beyond the current 90.
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.
MIT — see LICENSE.
List the controlled domain vocabulary used by the provider registry (e.g. 'health', 'legal', 'finance', 'earth-science').
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| domains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds context about the vocabulary being controlled, but does not disclose any additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that is front-loaded with the action and includes examples. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and no parameters, the description fully covers the purpose and scope. Examples provide additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter details. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists a controlled domain vocabulary, with specific examples ('health', 'legal', etc.). It is distinct from sibling tools like opendata_providers_list, which list providers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it i.e., when needing the domain vocabulary. It does not explicitly state when not to use it or provide alternatives, but for a simple list tool, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain the scoring breakdown for a provider search. Shows how each provider was ranked using token matching, fuzzy matching, semantic similarity, and metadata filters.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of top providers to explain (1-20, default 5). | |
| query | No | The original search query to explain scoring for. | |
| domain | No | Domain filter used in search. | |
| region | No | Region filter used in search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the tool is known to be safe. The description adds substantive behavioral detail by listing the scoring components (token matching, fuzzy matching, semantic similarity, metadata filters), which goes beyond what annotations provide. It does not mention edge cases like null query, but this is not a major gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main purpose, and contains no filler. Every sentence earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description is fairly complete. It explains the tool's purpose and what it shows, though it does not describe the exact return format. Given the simplicity of the tool and high schema coverage, this is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add significant meaning beyond indicating these parameters relate to the original search and filters, but it does not compensate beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Explain' and clearly identifies the resource ('the scoring breakdown for a provider search'). It distinguishes this tool from sibling tools like opendata_providers_find (which presumably performs the search) and opendata_federate_compare (which compares federated results).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is used after a provider search to understand ranking, but it does not explicitly mention alternatives or when not to use it. It provides clear context without exclusions, which aligns with a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Federate several plugin tool calls and report a coverage matrix — which sources cover which geographies and periods — alongside the merged series. Use this to spot gaps or disagreements between open-data sources.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | No | Sub-calls to run and harmonize. Each names a plugin tool and its arguments; results are normalized onto a common geography + time axis and merged. | |
| harmonize | No | Which axes to normalize. {'geo': true, 'time': true} by default — set either false to pass that axis through raw. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds that it makes sub-calls to plugin tools, which is already in the schema. It does not add significant behavioral detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description outlines the outputs (coverage matrix and merged series). For a federated tool, it is fairly complete, though could mention potential performance or timeout considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds meaningful context: 'queries' sub-calls are normalized onto a common geography + time axis, and 'harmonize' controls which axes are normalized. This clarifies the merging behavior beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool federates plugin tool calls and reports a coverage matrix alongside merged series, with a specific use case ('spot gaps or disagreements'). It distinguishes from sibling tools like opendata_federate_query by adding coverage reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for use ('spot gaps or disagreements between open-data sources'), but does not explicitly state when not to use or provide alternatives. The differentiation from opendata_federate_query is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run several plugin tool calls, normalize their results onto a common geography + time axis, and merge them into one cited series. Auto-activates each query's provider. Use this to overlay the same indicator from different open-data sources (e.g. Eurostat vs World Bank) in a single answer.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | No | Sub-calls to run and harmonize. Each names a plugin tool and its arguments; results are normalized onto a common geography + time axis and merged. | |
| harmonize | No | Which axes to normalize. {'geo': true, 'time': true} by default — set either false to pass that axis through raw. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds value by explaining normalization and merging behavior, auto-activation of providers, and that output is a 'cited series'. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: defining action, noting auto-activation, and providing a usage example. It is concise, front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested sub-queries, no output schema), the description explains orchestration well. It covers purpose, usage, and key behaviors. Missing details on error handling or output structure, but adequate for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about normalization and merging but doesn't add significant parameter-specific meaning beyond the schema. It explains the harmonize parameter implicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: run multiple plugin tool calls, normalize results onto common geography/time axes, and merge into one cited series. It distinguishes from siblings like opendata_tool_call (single call) and opendata_federate_compare (comparison) by specifying overlay of same indicator from different sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this to overlay the same indicator from different open-data sources' with examples (Eurostat vs World Bank). It implies when to use but lacks explicit when-not or alternatives. The auto-activation note adds context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Snapshot the in-memory provider health registry. Returns a score in [0.0, 1.0] for each requested provider (or every registered provider when called without arguments). Health degrades on recent 5xx / 429 / network failures and decays back toward 1.0 over ~5 minutes; 401/403 are excluded as caller misconfig. The discovery app uses this to paint live health badges next to each search result.
| Name | Required | Description | Default |
|---|---|---|---|
| provider_ids | No | Optional list of provider ids to query. When omitted, returns snapshots for every provider in the static + dynamic registry. Providers with no recorded failures default to a fully-healthy baseline (score 1.0). |
| Name | Required | Description |
|---|---|---|
| snapshot | No | |
| generated_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral details beyond annotations: health degrades on 5xx/429/network errors, decays over 5 minutes, excludes 401/403. This complements idempotentHint and readOnlyHint well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences), front-loaded with the primary action, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter and output schema present, the description fully covers behavior with/without arguments, failure recovery, and use case. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds context: optional provider_ids default to null, behavior when omitted (returns all providers), and baseline score for healthy providers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool snapshots the in-memory provider health registry and returns a score per provider, distinguishing it from sibling tools like opendata_providers_list which list providers without health context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (to get health scores for one or all providers) and provides business context (painting health badges), but does not explicitly state when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Autonomously create a new plugin for this meta-data-mcp server from a YAML spec. Use this when opendata_providers_find returned no match. Recommended flow: first call opendata_plugins_draft with structured fields to get a valid YAML spec, then pass it here. The new plugin is materialized to disk, imported, registered in the live registry, and its tools become available immediately. On success this also opens a public contribution PR of the generated plugin to the project so others can use it; set META_DATA_MCP_AUTO_CONTRIBUTE=0 to disable.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | No | Registry domains for the new plugin (e.g. ['security']). Use `opendata_domains_list` to see existing values, but new domain names are allowed. | |
| regions | No | Registry regions for the new plugin (e.g. ['global', 'us']). Use `opendata_regions_list` to see existing values. | |
| keywords | No | Search keywords that should match this plugin. | |
| spec_yaml | Yes | Full YAML spec for the new plugin. Must include id, server_name, base_url, description, homepage, and at least one tool. See tools/specs/example_weather_alert.yaml for the canonical form. | |
| license_note | No | Optional short licensing/attribution note for the data source. | |
| requires_env | No | Names of any environment variables the new plugin needs (e.g. API keys). Leave empty for keyless APIs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: materialization to disk, import, registration, immediate availability, and auto PR. Annotations only indicate destructiveHint=false, so description adds value without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise paragraph with each sentence adding value: purpose, when to use, recommended flow, effects, and configuration hint. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete coverage given tool complexity: describes side effects, prerequisite flow, and configuration. References other tools for context. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 6 parameters with descriptions (100% coverage), so baseline is 3. The description does not add extra parameter-specific details beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new plugin from a YAML spec, specifies the verb 'create' and resource 'plugin', and distinguishes from siblings by referencing opendata_providers_find and opendata_plugins_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool ('when opendata_providers_find returned no match') and provides a recommended flow involving opendata_plugins_draft, plus mentions environment variable to disable auto-contribution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a validated YAML plugin spec from structured inputs. Use this BEFORE opendata_plugins_create to avoid hand-writing YAML. Validates id format, kebab-case tool names, path-placeholder/param consistency, parameter types, and response format. Returns the YAML string ready to feed into opendata_plugins_create.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Plugin id in snake_case, e.g. 'global_nvd_cve'. Becomes the Python module name under meta_data_mcp/providers/. | |
| title | Yes | Human-readable title for the registry entry. | |
| tools | Yes | At least one tool definition. Each becomes one MCP tool on the server. | |
| domains | No | Registry domains (e.g. ['security', 'government']). | |
| regions | No | Registry regions (e.g. ['global', 'us']). | |
| base_url | Yes | API base URL with no trailing slash (e.g. 'https://services.nvd.nist.gov'). | |
| homepage | Yes | URL to the API documentation or provider homepage. | |
| keywords | No | Search keywords that should match this plugin in opendata_providers_find. | |
| description | Yes | One- or two-sentence description of what this plugin covers. | |
| server_name | No | kebab-case server name for the plugin registry entry. Defaults to id with underscores replaced by hyphens. | |
| requires_env | No | Names of environment variables this API needs (e.g. ['NVD_API_KEY']). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. Description adds value by listing validations performed (id format, kebab-case, consistency checks) and output format, which are beyond the annotation scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with main purpose, then usage guidance, validation details, and output. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no output schema), the description adequately covers purpose, usage, validations, and output. It is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 11 parameters. Tool description does not add extra parameter information, but baseline is 3 when schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Build a validated YAML plugin spec from structured inputs' with specific verb and resource. It also distinguishes from sibling 'opendata_plugins_create' by stating usage order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this BEFORE opendata_plugins_create to avoid hand-writing YAML', providing clear context and alternative. Does not explicitly state when not to use, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Activate a registered provider so its tools become callable in this session. By default the server starts in discovery-only mode — only meta tools (find-providers, list-providers, etc.) are advertised. Activation imports the plugin module and merges its tools into the advertised list, then sends a tools/list_changed notification so the client refetches its catalog. Idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| provider_id | Yes | Provider id to activate (e.g. 'us_data_gov' or 'us-data-gov'). Use opendata_providers_find or opendata_providers_list to discover available ids. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| provider_id | No | |
| tools_added | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the idempotentHint annotation, the description details side effects: imports plugin, merges tools, sends tools/list_changed notification. This adds significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no waste. The key purpose is front-loaded, and every sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and an output schema, the description covers activation behavior, idempotency, and client notification fully. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and schema describes provider_id. The description adds value by advising to use opendata_providers_find or list for discovery, which aids parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool activates a registered provider to make its tools callable. It uses specific verb and resource ('activate a registered provider') and distinguishes from sibling tools like opendata_providers_deactivate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains activation is needed because the server starts in discovery-only mode. It implies when to use but doesn't explicitly list when not to use or alternatives beyond mentioning idempotency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a previously-activated provider's tools from the session's advertised list. The Python module remains imported (Python caches modules) but its tools no longer appear in tools/list. A tools/list_changed notification is sent so the client refetches.
| Name | Required | Description | Default |
|---|---|---|---|
| provider_id | Yes | Provider id to deactivate. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| provider_id | No | |
| tools_removed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the 'idempotentHint' annotation, the description discloses that the Python module remains imported (due to caching) and that a 'tools/list_changed' notification is sent. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary action, no filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema (as indicated by context signals), the description fully covers behavioral effects and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the description adds no additional meaning beyond the schema's 'Provider id to deactivate.' Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'remove' and the resource 'previously-activated provider's tools', specifying the effect on the advertised list. It distinguishes from the sibling 'opendata_providers_activate' by implying the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use (deactivate a provider) and contrasts with activation, but does not explicitly provide when-not-to-use or alternatives. It gives clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full registry entry for a single provider id — title, description, domains, regions, keywords, homepage, license note, required environment variables.
| Name | Required | Description | Default |
|---|---|---|---|
| provider_id | Yes | The provider id (e.g. 'us_nasa', 'global_world_bank', 'us_courtlistener'). |
| Name | Required | Description |
|---|---|---|
| id | No | |
| title | No | |
| domains | No | |
| regions | No | |
| homepage | No | |
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, and the description's 'Fetch' aligns with these. The description adds value by enumerating the returned fields (title, description, domains, etc.), providing context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that concisely conveys purpose and return fields without any fluff. Every part is informative and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (implied), the description adequately covers the tool's behavior. It lists the key fields returned and makes clear that this is a simple lookup by provider ID. No additional information is needed for this straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the input schema already includes a clear description of the required parameter 'provider_id' with examples. The description does not add additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and clearly identifies the resource as 'full registry entry for a single provider id', listing the included fields: title, description, domains, regions, keywords, homepage, license note, required environment variables. This clearly distinguishes it from sibling tools like opendata_providers_list (which lists multiple) and opendata_providers_find (which likely searches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like opendata_providers_find or opendata_providers_list. It implies usage for fetching details of a single provider by ID, but lacks guidance on when not to use it or what exclusions apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the meta-data-mcp plugin registry. Returns plugins that match a free-text query and/or domain/region filters. Use this FIRST when you don't know which plugin can answer a question. If no plugin matches, the response includes a next_step field that explains how to autonomously create one via opendata_plugins_create.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of providers to return (1-100, default 20). | |
| query | No | Free-text query. Matched against id, title, description, keywords, domains, regions. Tokens with exact keyword hits score higher. | |
| domain | No | Restrict to providers tagged with this domain (e.g. 'health', 'legal', 'finance'). Use opendata_domains_list to enumerate. | |
| region | No | Restrict to providers tagged with this region (e.g. 'us', 'eu', 'uk', 'global'). Use opendata_regions_list to enumerate. | |
| activate_top | No | If > 0, automatically activate the top-N matching providers so their tools become callable in this session. Default 0 means find-providers is read-only — you must call opendata_providers_activate explicitly to load tools. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description need not restate. It adds useful context about the next_step field for no matches. However, it fails to disclose that setting activate_top > 0 will activate providers, a side effect that contradicts the read-only implication of the default. Though the schema documents this, the description omits it, leaving a transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each substantive: purpose, when-to-use, and fallback behavior. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the discovery use case and the no-match fallback, and references an alternative creation tool. However, it omits the activate_top parameter's side effect, which is significant for an agent deciding whether to use this tool. The rich schema partially compensates, but the description is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all 5 parameters, achieving 100% schema description coverage. The description's mention of 'free-text query and/or domain/region filters' merely echoes schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search the meta-data-mcp plugin registry' with a specific verb and resource. It distinguishes itself from sibling tools by describing filtered search functionality and explicitly says to 'Use this FIRST when you don't know which plugin can answer a question.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use: 'Use this FIRST when you don't know which plugin can answer a question.' Also provides an alternative path by mentioning that if no plugin matches, the response includes a next_step field explaining how to autonomously create one via opendata_plugins_create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate all providers in the opendata-mcp registry (paginated, terse). Returns id, title, domains, regions, and any required env vars per provider.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of entries to return (1-200, default 50). | |
| offset | No | Number of entries to skip (default 0). |
| Name | Required | Description |
|---|---|---|
| limit | No | |
| total | No | |
| offset | No | |
| providers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm read-only and idempotent behavior. Description adds important behavioral details: pagination, terse output, and inclusion of env vars per provider, which exceeds annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys purpose, pagination, terse nature, and return fields—no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paginated list tool with complete schema coverage, an output schema, and clear return field description, the description is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described limit and offset parameters. Description mentions pagination generically but adds no new semantic detail beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Enumerate all providers in the opendata-mcp registry' with specific return fields, effectively distinguishing from siblings like opendata_providers_list_active which presumably filters only active ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies full listing but does not explicitly advise when to use this tool over alternatives like opendata_providers_list_active, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the providers currently activated in this session, along with the tool names each contributes. Useful for inspecting why a particular tool is (or isn't) advertised.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | No | |
| meta_tool_count | No | |
| active_providers | No | |
| plugin_tool_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it specifies that the tool returns currently activated providers and the tool names they contribute. This aligns with the readOnlyHint and idempotentHint annotations, and no contradictions are present. The behavioral insight into inspection of tool advertising adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core action ('List the providers') followed by a practical usage scenario. Every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of parameters, the presence of annotations (readOnly, idempotent), and an output schema (not shown), the description sufficiently explains the tool's function and usage. It is complete within its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and 100% coverage, so the description does not need to elaborate. The baseline for zero parameters is 4, and the description appropriately omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists active providers with their contributed tool names, distinguishing it from sibling 'opendata_providers_list' which likely lists all providers. The specific verb 'list' and resource 'active providers' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage hint: 'Useful for inspecting why a particular tool is (or isn't) advertised.' This implies when to use, but it does not explicitly contrast with alternatives like opendata_providers_list or opendata_providers_describe. A more direct comparison would strengthen this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the controlled region vocabulary used by the provider registry (e.g. 'us', 'eu', 'uk', 'global').
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the context that this is a controlled vocabulary with examples, but doesn't disclose further behavioral details like pagination or return format. This is acceptable given the annotations and simplicity, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and includes examples. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool, the description is completely adequate. It explains what the tool returns (a list of region codes) and provides examples, without needing to explain return values or side effects. No output schema exists, but the description covers the key information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (nothing to document). The description explicitly notes 'no parameters' in the schema and doesn't need to add parameter details. Baseline for 0 params is 4, and no additional explanation is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists a controlled region vocabulary for the provider registry, with concrete examples ('us', 'eu', 'uk', 'global'). The verb 'List' and resource are specific, and it distinguishes itself from sibling tools focused on providers or queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by noting the vocabulary is 'used by the provider registry', making it clear this is a reference for valid region values. It doesn't explicitly mention alternatives or exclusions, but for a simple list tool, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Proxy any activated plugin tool by name. Use this when dynamically activated tools aren't directly callable in your environment. First activate the provider with opendata_providers_activate, then call this tool with the tool name and arguments from the activation response's tool_schemas field.
| Name | Required | Description | Default |
|---|---|---|---|
| arguments | No | Arguments to pass to the tool, matching its inputSchema. | |
| tool_name | Yes | Exact name of an activated plugin tool to call (e.g. 'nvd-search-cves'). Use opendata_providers_activate first, then pass the tool name from its 'tools' list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context about activation requirements but contradicts the annotations. The tool is described as calling dynamic tools, which may write or mutate data, yet annotations set readOnlyHint=true and idempotentHint=true. This is a significant inconsistency that misleads about the tool's side effects. Without the contradiction, the description would score higher for explaining the proxy mechanism.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: stating functionality, explaining use case, and providing workflow steps. No redundant or unnecessary text. Highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a proxy with no output schema, the description adequately explains the prerequisite activation and how to obtain the tool name. However, it does not address error handling (e.g., what if the target tool fails) or confirm the idempotency hinted by annotations. Slight gap but mostly complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so baseline is 3. The description adds valuable meaning for 'tool_name' by specifying it should come from the activation response's 'tools' list and providing an example ('nvd-search-cves'). For 'arguments', only minimal restatement. Overall, description improves understanding of parameter origin and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Proxy any activated plugin tool by name.' It distinguishes itself from sibling tools by explaining it is for dynamically activated tools that aren't directly callable. The verb 'proxy' and resource 'activated plugin tool' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: 'when dynamically activated tools aren't directly callable in your environment.' It also provides a clear two-step workflow: first activate with opendata_providers_activate, then call with tool name and arguments. However, it does not explicitly mention alternatives or when not to use, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v3.3.0opendata_explain_choice1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "query": {
- "type": [
- "string",
- "null"
- ]
- },
- "results": {
- "items": {
- "type": "object"
- },
- "type": "array"
- }
- },
- "type": "object"
-}New value: +nullopendata_providers_find1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "count": {
- "type": "integer"
- },
- "next_step": {
- "type": "string"
- },
- "no_match": {
- "type": "boolean"
- },
- "providers": {
- "items": {
- "type": "object"
- },
- "type": "array"
- }
- },
- "type": "object"
-}New value: +nullopendata_regions_list1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "regions": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
-}New value: +nullv3.2.0opendata_federate_compareopendata_federate_queryv0.1.0opendata_domains_listopendata_explain_choiceopendata_health_snapshotopendata_plugins_createopendata_plugins_draftopendata_providers_activateopendata_providers_deactivateopendata_providers_describeopendata_providers_findopendata_providers_listopendata_providers_list_activeopendata_regions_listopendata_tool_callScored across 15 tools
Every tool serves a distinct purpose: provider discovery vs activation vs health, plugin drafting vs creation, federated query vs comparison. Even the two federate tools are clearly separated by output (merged series vs coverage matrix). No two tools appear to duplicate each other.
The vast majority follow the 'opendata_<resource>_<verb>' pattern (e.g., providers_list, plugins_create, health_snapshot). However, three tools deviate with verb-object order (federate_query, federate_compare, explain_choice), which is a minor inconsistency in an otherwise readable and predictable scheme.
15 tools is at the upper edge of the ideal range but perfectly appropriate for the server's scope: it manages providers, plugins, health monitoring, federation, and vocabulary. Each tool earns its place with a clear role, and none feel redundant or excessive.
The core workflows are well covered: discover providers, activate/deactivate, run federated queries, and create new plugins. The only minor gaps are the absence of an explicit update/delete lifecycle for plugins (though plugin creation is the intended path) and no unregister operation for providers beyond deactivation. These do not prevent typical agent workflows.
One MCP server over 253 data sources: Reddit, LinkedIn, YouTube, G2, search and AI answers.
28 MCP servers behind one endpoint: earth, sky, policy, records and research
One MCP server for 180+ live web-data APIs returning clean JSON from sites that block scrapers.
Hosted MCP server for finding authoritative primary data sources and official portals.
