How do I use CKAN MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CKAN MCP Server search for datasets about air quality in New York City" 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.

CKAN MCP Server

by openascot

Overview Schema Source Related Servers Score Discussions Admin

Python

Hybrid

CKAN MCP Server (Python)

A Model Context Protocol (MCP) server that exposes the 600 plus¹² global CKAN open-data portals to AI assistants, CLI tools, and other MCP-aware clients. It bundles curated portal presets, strict Pydantic models, and a batteries-included tool suite so analysts, application developers, and operators can explore public datasets without writing bespoke CKAN integrations.

Persona-centric Guidance

Persona	Primary questions	Suggested section
Curious evaluators	"What can this server do?" "Which CKAN actions are covered?"	Potential users
Data analysts / MCP end-users	"How do I set it up locally?" "How do I connect to a remote MCP server?"	Data analysts
Contributors / maintainers	"How is the code organized?" "How do I run tests?"	Developers
Platform / infra teams	"Can I deploy this to Cloud Run?"	Production deployment

Potential Users: What This Server Does

Why it exists

Purpose-built CKAN interface: Wraps the CKAN Action & Datastore APIs behind MCP tools that AI agents and CLI clients understand.
Consistent insights: Presents dataset summaries, freshness analysis, schemas, and download helpers so exploratory conversations stay grounded in real CKAN metadata.
Portal-aware behavior: Curated overrides (transport method, dataset URL templates, helper prompts) keep the experience consistent across CKAN portals that deviate from defaults.

Tool catalog (14 tools)

Category	Tool	What it returns
Session configuration	`ckan_api_initialise`	Selects a portal (country/location + overrides) and stores API keys/session metadata.
	`ckan_api_availability`	Lists the configured CKAN portals and reports the current session's selection (when set).
	`audit_ckan_api`	Probes GET/POST behavior, datastore aliases, and helper metadata; emits recommended overrides for future sessions.
Dataset retrieval	`get_package`	Full CKAN dataset metadata (resources, organization, extras).
	`list_datasets`	Paginated package list with optional total counts.
	`search_datasets`	Action API `package_search` wrapper with passthrough Solr parameters.
	`get_data_categories`	Organizations and groups for navigation.
Datastore access	`get_first_datastore_resource_records`	Pulls preview rows from the first active datastore resource.
	`get_resource_records`	Targeted datastore search with filters, sorts, distinct, etc.
	`download_dataset_locally`	Metadata-rich archive/download helper with MIME detection, extraction, and how-to snippets.
Analysis	`find_relevant_datasets`	Weighted scoring across title/description/tags/org/resource metadata.
	`analyze_dataset_updates`	Frequency heuristics plus CKAN update timestamps.
	`analyze_dataset_structure`	Schema summaries, record counts, sample fields.
	`get_dataset_insights`	Combines discovery, updates, structure, and helper prompts into one rich response.

Architecture at a glance

src/ckan_mcp/main.py – MCP server entry point supporting stdio and HTTP (SSE) transports.
src/ckan_mcp/ckan_tools.py – Tool implementations, transport probes, download helpers, and archive extraction.
src/ckan_mcp/helpers.py – Relevance scoring, update frequency analysis, summary builders.
src/ckan_mcp/types.py – Strict Pydantic models with extra="allow" for portal-specific metadata.
src/ckan_mcp/config_selection.py & src/ckan_mcp/data/ckan_config_selection.json – Curated CKAN portal catalog and overrides consumed by ckan_api_initialise.
tests/ & test_runner.py – Pytest suite plus quick smoke runner mirroring production behaviors.

Tip: start with ckan_api_initialise to choose a portal, then call the analysis tools to see the depth of insights returned.

Data Analysts: Getting Insights Fast

Shared prerequisites

CKAN portal URL (or use the curated list during initialization).
Python 3.11+ and uv or pip for installing dependencies.
curl and the POSIX file command on your PATH (the download_dataset_locally tool shells out to both binaries).
An MCP-compatible client (Claude CLI, Gemini CLI, etc.).

Option A – Run the MCP server locally

Clone & create a virtual environment

git clone https://github.com/<org>/ckan-mcp.git
cd ckan-mcp
uv venv venv
source venv/bin/activate

Install runtime dependencies
```
uv pip install -e .
```
(Add ".[dev]" for development tooling and ".[examples]" if you want to run the sample scripts that load .env files.)

Optional defaults – export CKAN env vars if you always talk to the same portal:

export CKAN_BASE_URL="https://ckan0.cf.opendata.inter.prod-toronto.ca/api/3/action"
export CKAN_SITE_URL="https://ckan0.cf.opendata.inter.prod-toronto.ca"
export CKAN_DATASET_URL_TEMPLATE="https://ckan0.cf.opendata.inter.prod-toronto.ca/dataset/{name}"

These are fallback values; interactive sessions normally rely on ckan_api_initialise to pick a portal.

Launch in stdio mode (best for desktop MCP clients):
```
python -m ckan_mcp.main
```

Connect your MCP client – example Claude CLI snippet (see core environment variables for transport overrides):

{
  "mcpServers": {
    "ckan-mcp": {
      "command": "python",
      "args": ["-m", "ckan_mcp.main"],
      "env": {
        "CKAN_MCP_LOCAL_DATASTORE": "~/dataset-store/",
      }
    }
  }
}

Start a session – ask your assistant to "Initialize a CKAN connection"; it will call ckan_api_initialise and then the discovery tools.

Option B – Use a remote MCP server with a local client

This flow is perfect when someone else operates the MCP server on shared infrastructure and you only need local MCP tooling.

Server operator sets up HTTP transport:
```
export CKAN_MCP_MODE=http
export CKAN_MCP_HOST=0.0.0.0
export CKAN_MCP_PORT=8000
python -m ckan_mcp.main
```
or run docker compose up --build to expose http://localhost:8000/mcp and front it with your preferred reverse proxy.
Expose the /mcp endpoint via HTTPS (Cloud Run, Fly.io, Tailscale, etc.) and share the URL with analysts.
Analyst registers the remote MCP server (Claude CLI example):
```
claude mcp add --transport http ckan-mcp https://mcp.example.com/mcp
claude mcp list
```
Gemini CLI uses gemini mcp add --transport http ckan-mcp https://mcp.example.com/mcp with the same URL.
Use normally – all CLI/desktop prompts now tunnel through the remote MCP server. The analyst still decides which CKAN portal to inspect via ckan_api_initialise.

Day-to-day usage tips

ckan_api_availability lists every CKAN portal packaged with this MCP build and reiterates which portal is currently selected (if any) before issuing expensive searches.
find_relevant_datasets quickly surfaces top matches for natural-language prompts; follow up with get_dataset_insights for a detailed brief.
download_dataset_locally writes metadata, datastore previews, and shell instructions to ~/.cache/ckan-mcp/... so you can pivot to pandas immediately.

Developers: Extend and Contribute

Repository map

src/ckan_mcp/
├── main.py          # MCP entry point + HTTP transport
├── ckan_tools.py    # Tool implementations & download helpers
├── helpers.py       # Scoring, frequency, and summary helpers
├── types.py         # Pydantic models
├── config_selection.py # Catalog loader & helper utilities
├── data/
│   └── ckan_config_selection.json # Curated CKAN catalog & overrides
└── __init__.py

Supporting files: pyproject.toml (uv/poetry style metadata), tests/, test_runner.py, examples/ for fixtures, and Docker/Make targets for container workflows.

Local development workflow

Activate the virtualenv and install dev dependencies:
```
source venv/bin/activate
uv pip install -e ".[dev]"
```
Run formatters and linters (Black first, then Ruff as required by the project guidelines):
```
black src/ tests/
ruff check src/ tests/ --fix
```
Type checking:
```
mypy src/
```
Tests:
```
pytest tests/ -v
python test_runner.py  # lightweight smoke run
# Live integration tests against the curated CKAN portals
CKAN_RUN_INTEGRATION_TESTS=1 pytest tests/ -m integration -v
```
Integration tests talk to the public CKAN portal configured via CKAN_TEST_COUNTRY/CKAN_TEST_LOCATION (defaults to Canada/Toronto) and accept overrides such as CKAN_TEST_BASE_URL, CKAN_TEST_SITE_URL, CKAN_TEST_DATASET_URL_TEMPLATE, or CKAN_TEST_SEARCH_TERMS for custom portals.
GitHub Actions verification (optional, requires the GitHub CLI authenticated against openascot/ckan-mcp-private):
```
# trigger the full workflow (lint/unit + integration jobs) for your current branch
gh workflow run ci.yml --ref "$(git rev-parse --abbrev-ref HEAD)"
# tail the logs for the most recent run
gh run watch
gh run view --log-failed
```
The workflow only runs when triggered manually; the quality-checks job runs Black/Ruff/mypy, and the dependent pytest-suite job reuses .github/workflows/pytest.yml to execute the standard pytest run plus the integration suite (with CKAN_RUN_INTEGRATION_TESTS=1). Trigger the standalone Pytest workflow directly if you only need the testing jobs.

Docker-based workflow (optional, HTTP transport exposed at http://localhost:8000/mcp):

make dev                 # foreground dev stack with reload
make quick-start         # background stack, uses docker-compose.dev.yml
make dev-tools           # helper container via the tools profile
make shell               # attach to the running dev app container
make test-production     # builds docker-compose.yml and curls /mcp

Follow the AGENTS.md guidance for naming, docstrings, and how to place fixtures under examples/. Always update or add pytest coverage alongside new tools or helper behaviors.

See CHANGELOG.md for release history and public milestone notes.

Contributing checklist

Create a feature branch and keep commits focused.
Add or update tests under tests/ mirroring the target module name (e.g., tests/test_ckan_tools.py).
Run pytest, black, ruff, and mypy locally (or via the docker helpers) before opening a PR.
Document new environment variables or tool behaviors in this README or EVALUATION_GUIDE.md as appropriate.

Production Deployment (Google Cloud Run Example)

Cloud Run pairs nicely with the built-in HTTP transport. The following example assumes you have the Google Cloud CLI configured and Artifact Registry enabled.

Build and push the container (uses the included multi-stage Dockerfile):

export PROJECT_ID="my-gcp-project"
gcloud auth configure-docker
gcloud builds submit --tag gcr.io/$PROJECT_ID/ckan-mcp

Deploy to Cloud Run:

gcloud run deploy ckan-mcp \
  --image gcr.io/$PROJECT_ID/ckan-mcp \
  --region us-central1 \
  --platform managed \
  --allow-unauthenticated \
  --port 8000 \
  --set-env-vars CKAN_MCP_MODE=http,CKAN_MCP_HTTP_PATH=/mcp,CKAN_MCP_HTTP_ALLOW_ORIGINS=* \
  --set-env-vars CKAN_BASE_URL=https://ckan0.cf.opendata.inter.prod-toronto.ca/api/3/action,CKAN_SITE_URL=https://ckan0.cf.opendata.inter.prod-toronto.ca

Adjust env vars for your preferred portal or omit them so analysts always call ckan_api_initialise.

Share the endpoint – Cloud Run will emit a URL such as https://ckan-mcp-12345-uc.a.run.app. Provide the /mcp path to clients (https://ckan-mcp-12345-uc.a.run.app/mcp).
Register with MCP clients – same claude mcp add --transport http ... flow as in the analyst section.
Operational tips:
- Set CKAN_MCP_HTTP_JSON_RESPONSE=true if your proxy expects JSON instead of SSE.
- Use Secret Manager to supply CKAN_API_KEY for locked-down portals.
- Monitor Cloud Run metrics; the server makes outbound HTTPS calls to CKAN only when tools are invoked.

Configuration Reference

Core environment variables

Variable	Default	Purpose
`CKAN_BASE_URL`	none	Optional default Action API base; sessions can override via `ckan_api_initialise`.
`CKAN_SITE_URL`	none	Root site URL used for dataset links.
`CKAN_DATASET_URL_TEMPLATE`	none	Overrides dataset page URL format (`{name}` and `{id}` supported).
`CKAN_API_KEY`	none	API key used when the selected portal requires authentication.
`CKAN_MCP_MODE`	`stdio`	`stdio` for CLI integrations, `http` for streamable HTTP transport.
`CKAN_MCP_HOST`	`0.0.0.0` (HTTP mode)	Bind host when `CKAN_MCP_MODE=http`.
`CKAN_MCP_PORT`	`8000`	Bind port for HTTP mode.
`CKAN_MCP_HTTP_PATH`	`/mcp`	Mount path for HTTP transport (used both by builtin HTTP server and Cloud Run deployments).
`CKAN_MCP_HTTP_ALLOW_ORIGINS`	`*`	CORS allowlist for HTTP mode.
`CKAN_MCP_HTTP_JSON_RESPONSE`	`false`	Emit JSON responses instead of SSE when `true`.
`CKAN_MCP_HTTP_LOG_LEVEL`	`info`	Log verbosity for HTTP transport.
`CKAN_MCP_LOCAL_DATASTORE`	`./` (current directory)	Local directory path where downloaded datasets are stored. Defaults to
current working directory if not set.

CKAN portal overrides

The curated catalog in src/ckan_mcp/data/ckan_config_selection.json contains entries such as Toronto, NYC, etc. Each location can provide overrides like:

action_transport: force GET vs POST for /api/3/action calls.
datastore_id_alias: whether datastore_search accepts id instead of resource_id.
requires_api_key: block initialization until an API key is supplied.
helper_prompt: user-facing reminder echoed in tool responses.
Pagination settings (default_search_rows, max_search_rows, default_preview_limit).

Call audit_ckan_api after selecting a portal to get automatically generated override recommendations, helper prompt text, and config snippets that can be pasted back into the catalog or used ad hoc via ckan_api_initialise(overrides={...}).

Sources / References

DataShades, CKAN Instances, accessed November 30, 2025, https://datashades.info/.
↩
commondataio/dataportals-registry, accessed November 30, 2025, https://raw.githubusercontent.com/commondataio/dataportals-registry/refs/heads/main/data/datasets/bysoftware/ckan.jsonl.
↩

Available Tools

14 tools

analyze_dataset_structureC

Deep data structure analysis with field definitions

ParametersJSON Schema

Name	Required	Description
`packageId`	Yes	The ID of the dataset to analyze
`includeDataPreview`	No	Whether to include sample data records
`previewLimit`	No	Number of sample records to include
`previewOffset`	No	Offset for the sample data preview
`previewFilters`	No	Datastore filters applied when fetching the preview sample.
`previewQ`	No	Datastore full-text query for the preview sample.
`previewPlain`	No	Disable text highlighting in preview results when true.
`previewDistinct`	No	Return only distinct rows in the preview sample.
`previewFields`	No	Subset of fields to include in the preview sample.
`previewSort`	No	Sort expression for preview samples.
`previewIncludeTotal`	No	Include the total record count in preview responses.
`previewRecordsFormat`	No	Datastore preview records format (e.g., objects or lists).

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure but provides minimal information. It mentions 'deep data structure analysis' but doesn't explain what this analysis returns, whether it's a read-only operation, performance characteristics, or any side effects. For a tool with 12 parameters and no annotation coverage, this is inadequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at just 7 words. It's front-loaded with the core purpose and wastes no words. Every word earns its place in conveying the tool's function, though it could benefit from additional context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 12 parameters, no annotations, no output schema, and many sibling alternatives, the description is incomplete. It doesn't explain what the analysis returns, how it differs from other dataset tools, or provide behavioral context. The 100% schema coverage helps with parameters, but the overall context for tool selection and understanding is insufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. It mentions 'field definitions' which relates to the analysis output but doesn't clarify parameter usage. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Deep data structure analysis with field definitions', which provides a general purpose (analyzing dataset structure) but is somewhat vague. It doesn't specify what 'deep analysis' entails or how this differs from sibling tools like 'get_dataset_insights' or 'get_package'. The verb 'analyze' is clear but lacks specificity about the analysis scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With 13 sibling tools including 'get_dataset_insights', 'get_package', and 'get_first_datastore_resource_records', there's no indication of when this analysis tool is preferred over other dataset inspection tools. No prerequisites or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyze_dataset_updatesC

Update frequency analysis with categorization

ParametersJSON Schema

Name	Required	Description
`query`	No	Search query to find datasets for analysis (optional if packageIds provided)
`packageIds`	No	Specific package IDs to analyze (optional if query provided)
`groupByFrequency`	No	Whether to group results by update frequency
`start`	No	Offset into the CKAN search result set when using the query parameter.
`fq`	No	Filter query for CKAN search when using the query parameter.
`sort`	No	Sort expression supported by package_search when using the query parameter.
`facetFields`	No	Facet fields to request alongside dataset search results.
`includePrivate`	No	Set true when using an API key and private datasets should be included.
`extraSearchParams`	No	Additional CKAN package_search parameters forwarded verbatim when using the query parameter.
`searchRows`	No	Maximum number of CKAN search rows to inspect when using the query parameter.

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for behavioral disclosure. The description mentions 'analysis' and 'categorization' but doesn't explain what the tool actually does behaviorally—whether it performs read-only queries, modifies data, requires authentication, has rate limits, or what the output looks like. For a tool with 10 parameters and no annotations, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at 5 words with no wasted language. It's front-loaded with the core purpose. However, this conciseness comes at the cost of completeness for a complex tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain what the tool returns, how the analysis works, what 'categorization' entails, or behavioral aspects. The agent must rely entirely on the schema and guesswork for a non-trivial analysis tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 10 parameters. The description adds no parameter-specific information beyond what's in the schema—it doesn't explain how parameters interact (e.g., query vs packageIds), what 'categorization' means in relation to parameters like groupByFrequency, or provide usage examples. Baseline 3 is appropriate when schema does all the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Update frequency analysis with categorization' states the general purpose (analyzing update frequency with categorization) but is vague about the specific action and resource. It mentions 'analysis' but doesn't specify what exactly is analyzed (datasets) or how the categorization works. It doesn't clearly distinguish from siblings like 'analyze_dataset_structure' or 'get_dataset_insights'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or compare it to sibling tools like 'analyze_dataset_structure' or 'get_dataset_insights'. The agent must infer usage from the tool name and parameters alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

audit_ckan_apiC

Review the active CKAN endpoint for specification deviations and configuration overrides

ParametersJSON Schema

Name	Required	Description	Default
`packageId`	No	Optional dataset ID to target when testing datastore compatibility.
`resourceId`	No	Optional datastore resource ID to use when verifying id/alias support.

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'reviewing' and 'testing', which implies a read-only or diagnostic operation, but doesn't clarify if it's safe, requires authentication, has side effects, or details the output format. This leaves significant gaps in understanding the tool's behavior beyond its basic purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded and every part contributes to understanding, making it highly concise and well-structured for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of auditing an API endpoint, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'specification deviations' or 'configuration overrides' entail, how results are returned, or any behavioral traits like error handling. This leaves the agent with incomplete context for effective tool use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, fully documenting the two optional parameters. The description adds minimal value by implying the parameters are used for 'testing datastore compatibility' and 'verifying id/alias support', but doesn't provide additional syntax or usage context beyond what the schema already states. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('Review', 'testing', 'verifying') and resources ('active CKAN endpoint', 'specification deviations', 'configuration overrides'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'ckan_api_availability' or 'analyze_dataset_structure', which might also involve endpoint analysis, so it doesn't reach the highest score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or specific contexts for usage, leaving the agent to infer based on the purpose alone. This lack of explicit guidelines reduces its effectiveness in tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ckan_api_availabilityB

List the configured CKAN portals and show the current selection when available

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does (listing portals and showing selection) but doesn't describe the return format, whether it's read-only or has side effects, error conditions, or any performance or permission considerations. This leaves significant gaps for a tool that interacts with portal configuration.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that communicates both primary and secondary actions without wasted words. It's front-loaded with the main purpose and appropriately sized for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete for a tool that presumably returns structured information about CKAN portals. It doesn't explain what 'configured CKAN portals' means, what 'current selection' refers to, or the format of the response. For a tool with potential complexity in portal management, this leaves too many unanswered questions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description appropriately doesn't add parameter information, maintaining focus on the tool's purpose. This meets the baseline expectation for a zero-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with the verb 'List' and resource 'configured CKAN portals', and adds the secondary action 'show the current selection'. It doesn't explicitly distinguish from sibling tools like 'list_datasets' or 'audit_ckan_api', but the focus on portal configuration rather than datasets provides implicit differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. While it mentions 'when available' for the current selection, it doesn't specify use cases, prerequisites, or contrast with sibling tools like 'ckan_api_initialise' or 'audit_ckan_api' that might relate to portal configuration.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ckan_api_initialiseC

Select which CKAN portal this MCP session should use

ParametersJSON Schema

Name	Required	Description
`country`	No	Country name (e.g., Canada, United Kingdom)
`location`	No	Location within the country (e.g., Toronto)
`resetContext`	No	When true, clears the current CKAN selection before applying a new one.
`apiKey`	No	Optional CKAN API token for accessing restricted datasets.
`overrides`	No	Session-specific overrides for CKAN transport and metadata hints.

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool selects a CKAN portal but doesn't explain what this means operationally—e.g., whether it persists across sessions, affects other tools, or has side effects like authentication requirements. The description is too vague for a mutation-like tool (setting session context).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and efficiently communicates the core function, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, no output schema, and no annotations), the description is insufficient. It doesn't explain the tool's role in the CKAN workflow, how it interacts with siblings, or what happens after selection (e.g., error handling or session persistence). For a session-initialization tool, more context is needed to guide proper use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no additional parameter semantics beyond implying the tool configures a session. This meets the baseline of 3, as the schema does the heavy lifting, but the description doesn't enhance understanding of how parameters interact or affect tool behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Select which CKAN portal this MCP session should use.' It specifies the verb ('Select') and resource ('CKAN portal'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'ckan_api_availability' or 'audit_ckan_api', which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether it must be called before other CKAN tools), exclusions, or comparisons to siblings like 'ckan_api_availability'. This lack of contextual guidance leaves the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

download_dataset_locallyC

Download a dataset resource, metadata, and usage guide to the local filesystem using curl

ParametersJSON Schema

Name	Required	Description
`packageId`	Yes	The dataset ID or name to download
`resourceId`	No	Optional ID of the specific resource to download
`preferredFormat`	No	Preferred resource format to download (CSV, JSON, etc.)
`downloadTimeoutSeconds`	No	Maximum time allowed for the curl download

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the curl implementation and implies local filesystem storage, it doesn't describe what happens during download (e.g., file naming, directory structure, error handling), whether authentication is needed, or what happens if downloads fail. For a tool that writes to local filesystem with multiple parameters, this is insufficient 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for the tool's complexity and front-loads the essential information about what the tool does and how it works.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that downloads datasets to local filesystem with 4 parameters and no annotations or output schema, the description is incomplete. It doesn't explain what gets downloaded (beyond 'resource, metadata, and usage guide'), where files are saved, how they're organized, or what happens on success/failure. The agent lacks sufficient context to use this tool effectively without trial and error.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 four parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. The baseline of 3 is appropriate when the schema does all the parameter documentation work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Download') and target ('dataset resource, metadata, and usage guide') with implementation method ('using curl'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_package' or 'get_resource_records' which might retrieve similar content without local storage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when this tool is appropriate versus other dataset retrieval tools, or any constraints on usage. The agent must infer usage context from the tool name and description alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_relevant_datasetsC

Intelligent dataset discovery with relevance scoring

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query for finding relevant datasets
`maxResults`	No	Maximum number of results to return
`includeRelevanceScore`	No	Whether to include relevance scores in results
`start`	No	Offset into the CKAN result set (maps to Action API 'start').
`fq`	No	Filter query to narrow search results using CKAN's Solr syntax.
`sort`	No	Sort expression supported by package_search.
`extraSearchParams`	No	Additional CKAN package_search parameters to forward verbatim.
`facetFields`	No	List of facet fields to request from CKAN (defaults to organization, groups, tags).
`includePrivate`	No	Set true when using an API key and you want private datasets included.
`rows`	No	Override the number of CKAN rows requested before relevance re-ranking.

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'intelligent discovery' and 'relevance scoring', which hints at advanced search capabilities, but fails to describe critical behaviors like whether this is a read-only operation, what the output format looks like, pagination handling, rate limits, authentication requirements, or how relevance scoring is calculated. The description is too vague to adequately inform an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient phrase that front-loads the core concept ('Intelligent dataset discovery with relevance scoring'). There's no wasted space or redundant information. However, it could be more structured by explicitly separating purpose from behavioral details, but given its brevity, it scores well for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (10 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, output format, error handling, and differentiation from siblings. While the schema covers parameters well, the description fails to provide the contextual guidance needed for an agent to use this tool effectively, especially compared to similar tools in the server.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 10 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain how 'query' interacts with 'intelligent discovery' or what 'relevance scoring' means in practice). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Intelligent dataset discovery with relevance scoring' states the general purpose (discovering datasets with scoring) but is vague about the specific action and resource. It mentions 'relevance scoring' which differentiates it from basic search tools, but doesn't clearly distinguish it from sibling tools like 'search_datasets' or 'list_datasets' in terms of scope or methodology.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'search_datasets', 'list_datasets', and 'get_package', there's no indication of when this 'intelligent discovery' approach is preferred, what prerequisites exist, or any exclusions. Usage is implied by the name but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_data_categoriesC

Explore organizations and topic groups

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It vaguely suggests exploration but fails to clarify key traits such as whether this is a read-only operation, if it requires authentication, what the output format might be, or any rate limits. The lack of detail leaves the agent with insufficient information about how the tool behaves beyond its name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a single phrase, but it is under-specified rather than efficiently informative. It lacks front-loaded clarity and wastes the opportunity to add meaningful context. While brief, it does not earn its place by providing actionable insights, making it mediocre in structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity is low (0 parameters) but with no annotations or output schema, the description is incomplete. It does not explain what 'organizations and topic groups' refer to, how results are returned, or any behavioral nuances. For a tool in a data-focused context with siblings like 'list_datasets', more detail is needed to guide the agent effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not add parameter details, which is acceptable since there are none to explain. However, it could hint at implicit parameters (e.g., filters), but its vagueness limits value. A baseline of 4 is appropriate for zero-parameter tools, as there is little to compensate for.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Explore organizations and topic groups' is vague and tautological—it essentially restates the tool name 'get_data_categories' without specifying what 'explore' entails (e.g., list, retrieve, or browse). It lacks a clear verb-resource pairing and does not distinguish from siblings like 'list_datasets' or 'get_package', which are more specific. This leaves the purpose ambiguous for an AI agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or exclusions, nor does it reference sibling tools like 'list_datasets' or 'get_package' for comparison. This absence of usage instructions makes it challenging for an agent to determine appropriate invocation scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_dataset_insightsC

Comprehensive analysis combining multiple dimensions

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query for finding datasets to analyze
`includeUpdateFrequency`	No	Whether to include update frequency analysis
`includeDataStructure`	No	Whether to include data structure analysis
`maxDatasets`	No	Maximum number of datasets to analyze
`start`	No	Offset into the CKAN result set (maps to Action API 'start').
`fq`	No	Filter query to narrow search results using CKAN's Solr syntax.
`sort`	No	Sort expression supported by package_search.
`facetFields`	No	List of facet fields to request from CKAN (defaults to organization, groups, tags).
`includePrivate`	No	Set true when using an API key and you want private datasets included.
`rows`	No	Override the number of CKAN rows requested before filtering for analysis.
`extraSearchParams`	No	Additional CKAN package_search parameters to forward verbatim.

TDQS

C2.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure but provides minimal information. It mentions 'comprehensive analysis' but doesn't explain what this analysis entails, what format the results take, whether it's a read-only operation, performance characteristics, or any limitations. The description is too generic to guide an agent on what to expect from this tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (4 words) but under-specified rather than efficiently informative. While it's front-loaded with the only information provided, it fails to convey meaningful content about the tool's purpose or behavior. Conciseness should not come at the expense of clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 11 parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what insights are generated, what the output format looks like, or how this 'comprehensive analysis' differs from using multiple specialized tools. The description fails to compensate for the lack of structured metadata.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Comprehensive analysis combining multiple dimensions' is vague and tautological - it essentially restates the tool name 'get_dataset_insights' without specifying what kind of analysis it performs or what insights it provides. It doesn't clearly distinguish this from sibling tools like 'analyze_dataset_structure' or 'analyze_dataset_updates' which seem to perform more focused analyses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'analyze_dataset_structure', 'analyze_dataset_updates', 'find_relevant_datasets', and 'search_datasets' available, there's no indication of when this comprehensive analysis tool is preferable to more specialized tools or basic search functions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_first_datastore_resource_recordsC

Get records from the first active datastore resource in a dataset

ParametersJSON Schema

Name	Required	Description
`packageId`	Yes	The ID of the dataset containing the resource
`limit`	No	Maximum number of records to return
`offset`	No	Number of records to skip before returning results
`filters`	No	Datastore API filters to apply on the server (field:value mapping).
`q`	No	Full-text query applied by CKAN's datastore_search endpoint.
`plain`	No	When true, disables text highlighting in datastore results.
`distinct`	No	Return only distinct rows from the datastore resource.
`fields`	No	Subset of fields to return for each record.
`sort`	No	Sort expression understood by datastore_search (e.g., "column desc").
`includeTotal`	No	Include the total record count from CKAN even when limit=0.
`recordsFormat`	No	Optional datastore output format (e.g., objects or lists).

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It mentions 'first active datastore resource' which hints at selection logic, but doesn't explain what 'active' means, error handling, performance characteristics, authentication needs, or what format the records are returned in. For an 11-parameter tool with no annotation coverage, this is inadequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (11 parameters, no annotations, no output schema), the description is insufficiently complete. It doesn't explain what constitutes a 'record', what format they're returned in, how 'first active' is determined, error conditions, or performance expectations. For a data retrieval tool with many parameters, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 11 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain how parameters interact, provide examples, or clarify edge cases. Baseline 3 is appropriate when schema does all the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get records') and target ('from the first active datastore resource in a dataset'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'get_resource_records' which appears to serve a similar purpose, preventing a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'get_resource_records' or other dataset-related tools. There's no mention of prerequisites, constraints, or comparative use cases, leaving the agent without contextual usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_packageC

Fetch complete dataset metadata by ID

ParametersJSON Schema

Name	Required	Description	Default
`packageId`	Yes	The ID of the dataset to fetch
`summary`	No	Whether to return a summary instead of full metadata

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions fetching metadata but doesn't specify whether this is a read-only operation, if it requires authentication, what errors might occur, or the format of the returned data. This leaves significant gaps in understanding the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'complete dataset metadata' includes, potential response formats, or error conditions. For a tool that fetches data by ID, more context is needed to understand its full scope and limitations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, clearly documenting both parameters. The description adds no additional meaning beyond the schema, such as explaining what 'complete dataset metadata' entails or how the 'summary' parameter affects the output. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('fetch') and resource ('complete dataset metadata by ID'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'list_datasets' or 'find_relevant_datasets' that might also retrieve dataset information, so it falls short of a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'list_datasets' for listing and 'find_relevant_datasets' for searching, the agent is left to infer usage based on the name alone, which is insufficient for optimal tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_resource_recordsC

Get records from a specific datastore resource

ParametersJSON Schema

Name	Required	Description
`resourceId`	Yes	The ID of the resource to fetch records from
`limit`	No	Maximum number of records to return
`offset`	No	Number of records to skip (for pagination)
`filters`	No	Datastore API filters to apply on the server (field:value mapping).
`q`	No	Full-text query applied by CKAN's datastore_search endpoint.
`plain`	No	When true, disables text highlighting in datastore results.
`distinct`	No	Return only distinct rows from the datastore resource.
`fields`	No	Subset of fields to return for each record.
`sort`	No	Sort expression understood by datastore_search (e.g., "column desc").
`includeTotal`	No	Include the total record count from CKAN even when limit=0.
`recordsFormat`	No	Optional datastore output format (e.g., objects or lists).

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. 'Get records' implies a read operation, but the description doesn't mention pagination behavior (though parameters suggest it), rate limits, authentication requirements, error conditions, or what format the records come in. For an 11-parameter tool with complex filtering capabilities, this is inadequate behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a tool with comprehensive schema documentation. Every word earns its place, and there's no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 11 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'records' look like, how pagination works with limit/offset, what the filters syntax entails, or how this differs from sibling tools. With rich parameter schema but no behavioral context, the description leaves too many questions unanswered for effective agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 11 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. It doesn't explain relationships between parameters (like how filters, q, and fields interact) or provide usage examples. Baseline 3 is appropriate when the schema does all the parameter documentation work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get records from a specific datastore resource' clearly states the action (get) and target (records from datastore resource), but it's vague about scope and doesn't distinguish from sibling tools like 'get_first_datastore_resource_records' or 'search_datasets'. It provides basic purpose but lacks specificity about what kind of records or what makes this tool unique.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for dataset operations (like search_datasets, get_first_datastore_resource_records, list_datasets), there's no indication of when this specific datastore record retrieval tool is appropriate versus other data access tools. No context about prerequisites or alternatives is mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_datasetsB

List all available datasets with pagination

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of datasets to return
`offset`	No	Number of datasets to skip (for pagination)
`includeTotal`	No	When true, queries CKAN for the total dataset count (extra request).

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions pagination but doesn't describe response format, error conditions, rate limits, authentication needs, or whether this is a read-only operation. For a list tool with zero annotation coverage, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that communicates the core purpose and key feature (pagination) without any wasted words. It's appropriately sized and front-loaded with essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters with full schema coverage but no annotations and no output schema, the description provides minimal but adequate context for a basic list operation. However, it lacks details about response format, error handling, and differentiation from sibling tools, which would be helpful for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter semantics beyond mentioning 'pagination' (which relates to limit/offset parameters already described in schema). Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and resource 'datasets' with the scope 'all available', providing a specific purpose. However, it doesn't explicitly distinguish this tool from sibling tools like 'search_datasets' or 'find_relevant_datasets', which might offer filtering capabilities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'with pagination', which implies usage for handling large result sets, but provides no explicit guidance on when to use this tool versus alternatives like 'search_datasets' or 'find_relevant_datasets'. There are no when-not-to-use statements or prerequisite information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_datasetsC

Search datasets by keyword

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query to find relevant datasets
`limit`	No	Maximum number of results to return
`start`	No	Offset into the CKAN result set (maps to Action API 'start').
`fq`	No	Filter query to narrow search results using CKAN's Solr syntax.
`sort`	No	Sort expression supported by package_search (e.g., 'metadata_modified desc').
`rows`	No	Number of CKAN rows to request before applying the limit in this tool.
`extraSearchParams`	No	Additional CKAN package_search parameters to forward verbatim (e.g., include_drafts, fl, bf).
`facetFields`	No	List of facet fields to request from CKAN.
`includePrivate`	No	Set true when using an API key and you want private datasets included.

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Search datasets by keyword' implies a read-only operation but doesn't address important behavioral aspects like authentication requirements (implied by includePrivate parameter), rate limits, pagination behavior, error conditions, or what format the results will be returned in. The description provides minimal behavioral context beyond the basic operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at just three words, front-loading the essential information with zero wasted words. It efficiently communicates the core function without unnecessary elaboration, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what kind of results to expect, how they're structured, or provide any context about the search capabilities beyond the basic keyword mention. The agent would need to rely heavily on the parameter schema alone to understand this tool's full functionality.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema already documents all 9 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation entirely through the structured schema, with no value added by the description text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Search') and resource ('datasets'), and indicates the primary mechanism ('by keyword'). However, it doesn't explicitly differentiate this tool from sibling tools like 'find_relevant_datasets' or 'list_datasets', which appear to serve similar search/listing functions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that appear related to dataset discovery (find_relevant_datasets, list_datasets, get_package), the agent receives no help in selecting the appropriate tool for different search scenarios or understanding the trade-offs between them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

14 tool updatesv1.0.0Jan 11, 2026
- First observedanalyze_dataset_structure
- First observedanalyze_dataset_updates
- First observedaudit_ckan_api
- First observedckan_api_availability
- First observedckan_api_initialise
- First observeddownload_dataset_locally
- First observedfind_relevant_datasets
- First observedget_data_categories
- First observedget_dataset_insights
- First observedget_first_datastore_resource_records
- First observedget_package
- First observedget_resource_records
- First observedlist_datasets
- First observedsearch_datasets

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0

Scored 2026-04-18 07:00 across 14 tools

Disambiguation4/5

Most tools have clearly distinct purposes, with minimal overlap. However, 'list_datasets' and 'search_datasets' could be confused, as listing might imply a general retrieval while searching is more specific. The descriptions help differentiate them, but the boundary is slightly fuzzy.

Naming Consistency4/5

Tool names follow a consistent verb_noun pattern throughout, such as 'analyze_dataset_structure' and 'download_dataset_locally'. There are minor deviations like 'ckan_api_initialise' (British spelling) and 'get_first_datastore_resource_records' (longer name), but overall the naming is predictable and readable.

Tool Count5/5

With 14 tools, the count is well-scoped for a CKAN data portal server. Each tool appears to earn its place by covering distinct aspects like analysis, discovery, metadata fetching, and data retrieval, without feeling overly heavy or thin for the domain.

Completeness4/5

The tool surface provides strong coverage for dataset exploration, analysis, and retrieval, including CRUD-like operations (e.g., get, list, search). Minor gaps exist, such as no explicit update or delete tools for datasets, but agents can likely work around this given the server's focus on data discovery and analysis rather than management.

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Healthdata A
io.github.pipeworx-io
HealthData.gov MCP — wraps HealthData.gov CKAN API (free, no auth)
Government Data Health & Wellness
332
Public Data Ukraine Mcp A
io.github.varvararatta
Public Data Ukraine Mcp connects AI agents to real public APIs via MCP. Tools include
Government Data Open Data
52
Datagov A
io.github.pipeworx-io
Data.gov MCP — wraps Data.gov CKAN API (catalog.data.gov/api/3)
Government Data Open Data
342
Dynamik Public Data A
io.github.DynamikOrbits
Public tools to understand Dynamik, discover datasets, and connect account-scoped capabilities.
Open Data Research & Data
41

Appeared in Searches

Open Source Data Resources and Information

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/openascot/ckan-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server