CKAN MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
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.
Average 2.8/5 across 14 of 14 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ckan-mcp MCP server](https://glama.ai/mcp/servers/openascot/ckan-mcp/badges/card.svg)](https://glama.ai/mcp/servers/openascot/ckan-mcp)

Score Badge

Copy to your README.md:

[![ckan-mcp MCP server](https://glama.ai/mcp/servers/openascot/ckan-mcp/badges/score.svg)](https://glama.ai/mcp/servers/openascot/ckan-mcp)

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