Open Data MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ANTHROPIC_MODEL | No | Model used by the reference agent with the Anthropic Messages API. | claude-sonnet-5-5 |
| ANTHROPIC_API_KEY | No | API key for the Anthropic Messages API, needed only by the bundled reference agent (`open-data-mcp ask`); put it in `.env`. Without it the agent prints setup instructions and exits with code 2 — the MCP server, tests and offline evaluation never need a key. | |
| OPEN_DATA_PORTAL_URL | No | Base URL of the CKAN portal, so other CKAN portals can be tried. | https://data.gov.ua |
| OPEN_DATA_CACHE_TTL_S | No | TTL in seconds for cached dataset metadata (data itself is fetched on every query and never cached). | 300 |
| OPEN_DATA_TRUSTED_DOWNLOAD_HOSTS | No | Comma-separated list of hosts to trust explicitly for resource downloads, e.g. `data.gov.ua,opendata.gov.ua`. Needed behind an HTTP proxy that does the DNS resolving (no local DNS), where the SSRF guard cannot resolve resource hosts and refuses them. HTTPS is still required. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_datasetsA | Search open-data datasets. Returns IDs, titles, short descriptions, organization, license and dataset URL for each hit. |
| get_schemaB | Describe a resource's columns and how the schema was obtained (DataStore metadata = authoritative; inferred_from_file = best guess). Also lists the dataset's resources. |
| queryA | Run read-only SQL over one tabular resource (DataStore, CSV or JSON). The SQL always covers the whole resource or the call fails; only the returned rows are capped. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a distinct purpose: search_datasets for discovery, get_schema for structural metadata, and query for data extraction. There is no overlap or ambiguity in what each tool does.
search_datasets and get_schema follow a clear verb_noun pattern, but 'query' deviates as a bare verb. The inconsistency is minor and the names remain readable.
Three tools are within the typical well-scoped range (3-15). Each tool is essential for the core open-data workflow: discovery, inspection, and querying.
The surface covers search → schema → query, but there is no direct way to list resources for a dataset or retrieve full dataset metadata. The gap between search_datasets (returns dataset IDs) and get_schema (requires a resource ID) forces workarounds.