Skip to main content
Glama
ondata

CKAN MCP Server

by ondata

List CKAN Dataset Resources

ckan_list_resources
Read-onlyIdempotent

Assess dataset resources by listing format, size, DataStore availability, and download URL, optionally probing source portals for DataStore status.

Instructions

List all resources in a dataset with a compact summary.

Returns a focused table of resources showing format, size, DataStore availability, and download URL. Use this to quickly assess what files a dataset contains before deciding how to access the data.

Args:

  • server_url (string): Base URL of CKAN server

  • id (string): Dataset ID or name

  • format_filter (string): Filter resources by format, case-insensitive (e.g., "CSV", "json", "XLSX")

  • response_format ('markdown' | 'json'): Output format

Returns: Compact resource summary with name, ID, format, size, DataStore flag, and URL

Examples:

Typical workflow: ckan_package_search → ckan_list_resources (assess available files) → ckan_datastore_search (for resources with DataStore=true)

When a resource has DataStore=false but its download URL belongs to a different (source) portal, the tool can probe the source portal for DataStore availability and report source_datastore_active and source_portal_url so you can query the data there instead. This probing is OFF by default (it issues extra HTTP requests to hosts taken from the dataset's own resource URLs); set check_source_portal=true to enable it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesDataset ID or name
server_urlYesBase URL of the CKAN server
format_filterNoFilter resources by format, case-insensitive (e.g., 'CSV', 'json', 'XLSX')
response_formatNoOutput format: 'markdown' for human-readable or 'json' for machine-readablemarkdown
check_source_portalNoOpt-in (default false): when true, probes the source portal for DataStore availability when a resource URL points to a different CKAN instance. Issues extra HTTP requests to hosts taken from the dataset's resource URLs.
Behavior5/5

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

Discloses non-obvious probing behavior for source portal when check_source_portal=true, mentions extra HTTP requests, and contrasts with default (off). Annotations already provide readOnly/idempotent; description adds significant context 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.

Conciseness4/5

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

Well-structured with front-loaded purpose, then args/returns/examples/workflow/advanced behavior. Some redundancy with schema args, but overall each section serves a purpose. No fluff.

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

Completeness5/5

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

Very comprehensive given complexity: 5 parameters, no output schema, annotations provided. Covers purpose, parameters, examples, workflow, advanced behavior, and edge cases (source portal probing). Missing only minor details like default filter behavior.

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?

Schema coverage 100% already documents parameters, but description adds value: case-insensitivity of format_filter, side-effects of check_source_portal, and default values for response_format and check_source_portal. Exceeds baseline of 3.

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

Purpose5/5

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

Clearly states verb ('List all resources') and resource ('in a dataset'), specifies output ('compact summary with format, size, DataStore availability, download URL'), and distinguishes from siblings via workflow (after package_search, before datastore_search).

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

Usage Guidelines4/5

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

Explicitly says when to use ('quickly assess what files a dataset contains before deciding how to access the data') and provides typical workflow. Lacks explicit when-not-to-use or direct sibling comparison, but context is sufficient.

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

Install Server

Other Tools

Latest Blog Posts

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/ondata/ckan-mcp-server'

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