ontario-data-mcp

by sprine

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.2.2
Disambiguation4/5
Most tools have distinct purposes, though some remote query tools (query_resource, sql_query, preview_data) could cause minor confusion. Descriptions help differentiate their use cases.
Naming Consistency4/5
Tools follow a consistent verb_noun pattern with snake_case, but 'validate_result' breaks the pattern (verb_noun without underscore). Overall, naming is predictable.
Tool Count4/5
23 tools is on the higher end but justified given the comprehensive coverage of data portal operations: discovery, metadata, download, caching, geospatial, and querying.
Completeness4/5
Covers all major workflows from search to analysis. Minor gaps like lack of bulk operations or dataset update tools, but these align with the read-heavy nature of open data portals.
Average 4.3/5 across 23 of 23 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. Description adds the constraint on datastore_active, but lacks details on rate limits, error behavior, or pagination beyond limit/offset parameters.
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?
Very concise: a single sentence for purpose and constraint, then a labeled list of parameters. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, constraint, and parameter usage adequately. With output schema present, return values are not needed. Could mention error cases or resource existence checks, but not essential for standard use.
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 is 0%, so description compensates well by explaining each parameter: resource_id format, filters as key-value pairs, fields as column list, sort string examples, limit range, and offset for pagination. Adds meaning beyond schema types and defaults.
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?
Description states verb 'query' and resource 'resource via CKAN Datastore API', with emphasis on 'remote, no download needed'. This distinguishes from siblings like download_resource, but lacks explicit differentiation from sql_query or preview_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit constraint 'Only works for resources with datastore_active=True' provides a condition. However, no guidance on when to use this vs. alternatives like sql_query or preview_data, and no exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds filtering behavior but does not disclose other traits like response format or edge cases (e.g., empty results). It does not contradict annotations.
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?
Two short sentences plus parameter list. Purpose is front-loaded. No extraneous information. Every sentence is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so return details are covered. The description covers what the tool lists and how to filter. Missing details like ordering or pagination, but these are not critical for a list tool.
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 is 0%, so the description must compensate. The Args block explains each parameter: format_filter (with enum values SHP/KML/GEOJSON/None), limit (max per portal), portal (single portal). This adds significant meaning beyond bare parameter names.
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?
The description clearly states the tool finds datasets with geospatial resources (SHP, KML, GeoJSON). It uses a specific verb 'find' and resource, distinguishing it from siblings like search_datasets or list_resources.
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?
No explicit guidance on when to use this tool vs alternatives. The description implies usage through parameters but does not state when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds that it includes dataset counts and allows portal filtering, but does not disclose further behavioral traits (e.g., pagination, rate limits). It does not contradict 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?
The description is two sentences plus an Args section, very concise and front-loaded with the main purpose. Minimal waste, though the Args section could be integrated into the paragraph for even tighter structure.
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?
Given the presence of an output schema (not shown), the description does not need to explain return values. Both parameters are documented, the tool's purpose and scope are clear, and annotations cover safety. Complete for a simple list tool.
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 description coverage is 0%, so the description must compensate. The Args section provides clear meaning: 'Include dataset counts per organization' for include_counts and 'Narrow to one portal. Default: all portals' for portal, adding value beyond the schema's type definitions.
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?
The description clearly states 'List government ministries and organizations with dataset counts across all portals,' specifying the verb 'list', the resource 'organizations', and the scope 'across all portals'. This distinguishes it from sibling tools like list_portals or list_topics.
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?
No explicit guidance on when to use this tool versus alternatives like list_portals or search_datasets. The description only implies usage by listing parameters, but lacks when-to-use or when-not-to-use directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint true and destructiveHint false, so safety is clear. The description adds valuable behavioral details: query execution semantics, SQL dialect support, and specific data handling gotchas (COUNT vs SUM, semicolons) that go 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?
The description is front-loaded with a clear one-line purpose, followed by bulleted tips and an Args section. While comprehensive, some tips could be condensed without losing meaning. Overall well-organized and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's single parameter and the presence of an output schema, the description covers query construction thoroughly. It omits return format details, but that is acceptable since output schema exists. It addresses common pitfalls and usage patterns, making it complete for a cached query 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?
The input schema has 0% coverage for the sole parameter 'sql'. The description provides a minimal arg description with an example, but the extensive SQL guidance in the main text compensates partially. However, more structured parameter-specific details would improve semantics.
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 'Run a SQL query against locally cached data in DuckDB', specifying the action and resource. It distinguishes from siblings by emphasizing local cache and referencing table names from download_resource or cache_info, though it could more explicitly contrast with query_resource or sql_query.
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?
Provides extensive usage tips: use SUM not COUNT, DESCRIBE first, use RENAME for column normalization, use LIKE for semicolons, and quote table names. However, it lacks explicit guidance on when to choose this tool over alternative query tools like query_resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false. Description adds specific logic (comparing update frequency to last modification date) beyond annotations. Still, no mention of edge cases or potential errors, but sufficient for a read-only check.
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?
Two sentences: purpose first, then parameter detail. Efficient but could be slightly more concise. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the core logic and parameter format. Lacks mention of error handling or return interpretation, but output schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description explains dataset_id format with a concrete example, adding meaning beyond the bare schema type. Fully compensates for missing schema descriptions.
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?
The description clearly states the tool checks dataset freshness using update frequency and last modification date, a specific verb+resource that distinguishes it from siblings like cache_info or compare_datasets.
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?
No guidance on when to use this tool versus alternatives, such as cache_info or get_dataset_info. No explicit conditions or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds only that it compares metadata. It does not disclose potential caching, error behavior, or limitations beyond the example. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: first explains the purpose, second details the parameter with example and constraint. No wasted words, front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but inferred), the description is fairly complete for a comparison tool. It could clarify what 'metadata' includes, but overall sufficient for an agent to decide when to invoke.
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% description coverage, but the description adds crucial details: required prefix format (e.g., 'toronto:abc'), example values, and an explicit range of 2-5 IDs. This compensates well for the schema's lack of semantic hints.
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?
The description states 'Compare metadata side-by-side for multiple datasets (can be cross-portal),' which clearly identifies the action (compare) and resource (datasets). It distinguishes from siblings like get_dataset_info by emphasizing multiple datasets and cross-portal capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing 2-5 datasets, but lacks explicit guidance on when to use versus alternatives like find_related_datasets or get_dataset_info. No when-not-to-use or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, establishing safety. The description adds behavioral context: it searches only within the same portal and uses shared tags and organization as criteria. This goes beyond the annotations without contradicting them, giving the agent a clear understanding of 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 concise: three sentences total. The first sentence states the main purpose, the second adds the scope constraint, and the last two lines document parameters. No unnecessary words, and critical information is front-loaded. This is an optimal structure for tool descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (context signals indicate 'Has output schema: true'), the description does not need to explain return values. It covers the essentials: purpose, scope, and parameter details. However, it could hint at error handling or edge cases (e.g., no related datasets found). Overall, it is sufficiently complete for safe usage.
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 schema description coverage at 0%, the description must compensate. It provides meaningful semantics: dataset_id is described as 'Prefixed dataset ID (e.g. "toronto:ttc-ridership") or bare ID', and limit as 'Max related datasets to return'. However, it does not elaborate on bare ID format or default limit behavior, so it adds value but is not exhaustive.
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?
The description clearly states the tool's purpose: 'Find datasets related to a given dataset by shared tags and organization.' This provides a specific verb ('Find') and resource ('datasets related to a given dataset'), with a clear method ('shared tags and organization'). It distinguishes from sibling tools like search_datasets (general search) and get_dataset_info (single dataset info) by specifying the relational and scoped nature.
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?
The description includes a critical usage guideline: 'Searches within the same portal as the source dataset only.' This implies when to use (within-portal) and hints at when not to (cross-portal). While it does not explicitly list alternatives or exclusions, the context from sibling tools suggests appropriate use cases, making the guideline clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by disclosing that it returns sample values, which is beyond the structured 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?
The description is three sentences long, front-loaded with purpose, and each sentence contributes meaning. Could be slightly more concise, but overall efficient.
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?
Given that an output schema exists, the description does not need to explain return values. The description covers the purpose and both parameters adequately, making it complete for a simple read tool.
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 description coverage is 0%, but the description compensates by explaining that resource_id can be prefixed or bare and that sample_size controls sample row count. This adds meaningful semantics beyond the raw schema.
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?
The description clearly states the tool retrieves 'column schema and sample values' for a datastore resource, using a specific verb and resource type. This distinguishes it from sibling tools like preview_data or download_resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for schema inspection but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria. No guidance on prerequisites or context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's mention of 'fetched remotely' adds context without contradiction. It reinforces non-destructive behavior but does not add 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence for purpose, two bullet points for arguments. No redundant phrases. Information is front-loaded and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not detail return values. It covers input parameters adequately. However, it could mention that the preview is read-only and lightweight, but overall complete for a simple tool.
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?
Despite 0% schema description coverage, the description explains both parameters: resource_id format (prefixed or bare ID) and rows range (1-100). This adds significant meaning beyond type/required metadata.
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?
Description clearly states the tool previews the first N rows of a resource, with a specific verb and resource. It distinguishes from siblings like query_resource or load_geodata by emphasizing quick preview and remote fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quick previews but does not explicitly state when to use this tool over alternatives like query_resource or compare_datasets. No when-not-to-use or alternative comparisons provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds specific output details (size, table count, details for every cached resource), going 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Every sentence provides necessary information: first sentence states action, second specifies output details.
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?
Given zero parameters and an output schema, the description fully explains what the tool returns. No gaps remain.
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?
There are zero parameters, so the description does not need to explain them. It compensates by detailing the output, which adds value beyond the empty schema.
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?
The description uses the verb 'Get' and specifies the resource 'cache statistics and list all cached datasets', clearly distinguishing it from siblings like 'cache_manage' or 'refresh_cache'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the tool's function but does not provide explicit guidance on when to use it versus alternatives like 'cache_manage' or 'refresh_cache'. Context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by specifying 'including all resources', beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. First sentence states what it does, second gives parameter details. No wasted words.
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?
Given the presence of an output schema (unseen), the description need not explain return values. It adequately describes the tool's purpose and parameter, fitting the context of sibling tools.
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 schema has no description (0% coverage), so the description compensates by providing an example format for dataset_id ('toronto:ttc-ridership' or bare ID), adding meaning beyond the schema type.
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?
The description clearly states 'Get full metadata for a dataset including all resources', using a specific verb and resource. It distinguishes from siblings like 'get_resource_schema' and 'list_resources'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description is clear about what the tool does, it does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or specific contexts, relying on implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that the output includes platform type and descriptions, but does not disclose behavioral traits like pagination or speed.
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 sentence of 11 words, front-loaded with the core action and resource. Every word is informative.
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?
Given the tool has no parameters, annotations present, and an output schema, the description provides sufficient context for a simple listing operation. No additional information is necessary.
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?
No parameters exist, so schema coverage is 100%. The description adds no parameter information, which is acceptable given the baseline score of 4 for zero-parameter tools.
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?
The description clearly states the verb 'List', the resource 'data portals', and what is included ('platform type and descriptions'). It is specific and distinguishes this tool from siblings by focusing on portals.
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?
While the description does not explicitly state when to use or provide alternatives, the tool has no parameters and a straightforward purpose. The simplicity mitigates the need for heavy guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds that the tool returns 'formats and sizes' of resources, which provides behavioral context about the output beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences: one stating the purpose and output, and one specifying the parameter. It is front-loaded with the main action and contains no unnecessary information.
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?
Given the tool has one parameter and an output schema, the description is complete. It explains the tool's purpose, the parameter's format, and what the output contains (formats and sizes). The output schema likely details the return structure, so no additional explanation is needed.
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 one parameter 'dataset_id' with 0% description coverage (no schema description). The description compensates by providing a clear explanation and example ('e.g. "toronto:ttc-ridership" or bare ID'), adding significant semantic value beyond the schema.
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?
The description clearly states the tool lists all resources (files) in a dataset with their formats and sizes, using the verb 'list' and specifying the resource and output details. It distinguishes itself from siblings like 'download_resource' and 'get_resource_schema' by focusing on listing resources within a dataset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like 'get_dataset_info' or 'download_resource'. The usage is implied (list resources in a dataset), but no guidance on when not to use it or which sibling might be more appropriate is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and destructiveHint. The description adds that the tool caches data into DuckDB and describes the force_refresh parameter, providing behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one clear sentence plus two brief argument descriptions. No unnecessary words, and the structure is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description adequately covers purpose and parameters. It might miss details about prerequisites (e.g., DuckDB spatial extension), but overall is sufficient for a loading tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema documentation coverage, the description fully compensates by explaining both parameters: resource_id (prefixed or bare ID) and force_refresh (re-download even if cached), providing essential meaning.
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?
The description clearly states the tool's action: downloading and caching a geospatial resource into DuckDB with spatial support. It specifies supported formats (SHP, KML, GeoJSON), making the purpose specific and distinguishable from siblings that may not target DuckDB or spatial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for geospatial data loading to DuckDB but does not explicitly contrast with siblings like 'download_resource' or 'cache_manage'. No when-to-use or alternatives guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior (destructiveHint: true). The description adds valuable context that omitting resource_id refreshes all cached resources, clarifying the tool's scope. However, it does not disclose potential side effects (e.g., blocking, permissions) beyond the annotation.
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: two sentences with no redundant information. The main action is front-loaded, and the argument description is directly below. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description covers purpose and parameter behavior. It lacks details on error scenarios or sync/async behavior, but given the output schema and annotations, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the single parameter: 'resource_id: Specific resource to refresh (prefixed or bare ID), or omit to refresh all.' This adds format notes and default behavior, making the parameter self-documenting.
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?
The description clearly states the tool's function: 'Re-download cached resources to get the latest data.' This uses a specific action verb ('re-download') and resource ('cached resources'), effectively differentiating from siblings like cache_info (info) or check_freshness (check).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing latest data from cache but provides no explicit comparisons to sibling tools like download_resource or cache_manage. Without guidance on when to prefer this tool over alternatives, the description offers only implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false) are consistent. The description adds context about cached data dependency and parameter constraints (e.g., latitude range, radius positive). It does not disclose performance or error behavior, but with annotations covering safety, the description provides adequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a clean docstring with sections for each parameter. It is efficient without fluff, but could be slightly more concise by removing redundant mentions like 'for within_radius' after the list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters (2 required) and an output schema existing, the description covers all parameters with constraints and prerequisites. It explains the caching requirement and operation mapping, making it fairly complete for a complex geospatial query tool.
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 description coverage is 0%, but the description lists each parameter with constraints (e.g., latitude -90 to 90, radius_km > 0) and explains the operation types. This compensates for the schema gap, though it could clarify return format or limit behavior.
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?
The description starts with 'Run spatial queries against cached geospatial data,' which clearly states the verb and resource. It lists specific operations (contains_point, within_bbox, within_radius), distinguishing it from siblings like 'query_cached' or 'sql_query'.
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?
The description provides prerequisites (resource must be cached via load_geodata) and explains when to use each operation. However, it lacks explicit guidance on when not to use this tool compared to alternatives like 'query_cached'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds context about local caching, staleness info, supported formats, and automatic casting of numeric columns. No contradiction.
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 concise but includes essential info: purpose, supported formats, caching behavior, workflow, and parameter hint. It is front-loaded and avoids redundancy, though slightly dense.
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?
Given the low complexity (1 parameter, output schema exists, annotations present), the description covers all relevant aspects: formats, caching, casting, workflow, and parameter format. It is fully complete for its context.
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 one parameter with no description (0% coverage). The description adds format and examples (e.g., 'toronto:abc123' or bare ID), providing significant additional meaning beyond the schema.
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?
Description clearly states that the tool downloads and caches a dataset resource, supports specific formats, and places it in a workflow chain (search_datasets -> get_dataset_info -> download_resource -> query_cached). It distinguishes from sibling tools by specifying the caching and format handling.
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?
The description provides a workflow and mentions caching behavior and auto-casting, implying when to use the tool. However, it does not explicitly state when not to use or provide alternatives, though the workflow guides usage well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it uses DuckDB SUMMARIZE and checks duplicates, which is consistent. No contradictions, but does not elaborate on performance or error handling beyond the caching requirement.
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 concise, with a clear summary paragraph and an args section. It could be slightly more streamlined, but every sentence adds value. 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?
Given the tool has a single parameter and an existing output schema, the description is complete. It explains the tool's purpose, methodology, and parameter constraint. No additional information is needed for correct invocation.
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?
With 0% schema description coverage, the description adds crucial context: 'Resource ID (must be cached)'. This compensates for the schema's lack of documentation, clarifying the input requirement beyond mere type and required status.
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?
The description explicitly states it produces a 'statistical profile and quality check' using DuckDB SUMMARIZE, detailing column-level statistics and duplicate row checks. This clearly differentiates it from sibling tools like preview_data or query_cached.
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?
The purpose is distinct among siblings, focusing on profiling rather than querying or comparison. It mentions the resource must be cached, providing a key constraint. However, it lacks explicit when-to-use or when-not-to-use guidance relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe read-only behavior. The description adds value by explaining that the tool re-executes the SQL, extracts numbers and terms, and checks them against data. This covers the key behavioral aspects without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (around 60 words) and well-structured: an introductory sentence defining the tool's purpose, a usage recommendation, and a brief note on the execution process, followed by a clear parameter list. Every sentence adds value with no redundancy.
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?
The tool has an output schema (not shown), so the description does not need to detail return values. However, it does not mention what the output looks like (e.g., boolean, match report), which would be helpful for an agent to interpret results. Also lacks any mention of error conditions or limitations, leaving minor gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description provides full semantics for both required parameters: 'sql' is explained as 'the SQL query that produced the data backing the claim' and 'claim' as 'the natural-language claim to verify.' This completely compensates for the missing schema descriptions.
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?
The description clearly states the tool's purpose: 'Validate that a claim is supported by query results.' It specifies the action (validate) and the resource (claim), and distinguishes it from sibling tools like sql_query or compare_datasets by describing the verification process.
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?
The description provides explicit guidance: 'Call this after making a data claim to verify it against the source.' This clearly indicates when to use the tool, though it does not explicitly state when not to use it or mention alternatives beyond the context of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description's mention of removing or clearing cached data is consistent and adds specificity. It does not detail potential side effects (e.g., irreversible data removal), but the annotations cover the destructive nature, and the description provides operational clarity.
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 very concise: a single sentence followed by a clear list of parameters. Every sentence adds necessary information without redundancy. It is well-structured and front-loaded with the purpose.
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?
The tool has an output schema, so return values are not needed in the description. The description covers both parameters, their roles, and the two actions. For a cache management tool, this is complete and leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description fully compensates: it explains that 'action' accepts 'remove' or 'clear', and that 'resource_id' is required for 'remove' and accepts prefixed or bare IDs. This adds critical meaning beyond the bare schema.
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?
The description clearly states it manages the DuckDB cache with two specific actions: 'remove' (single resource) and 'clear' (all). The verb 'manage' combined with explicit actions leaves no ambiguity about the tool's purpose, distinguishing it from sibling tools like cache_info or refresh_cache.
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?
The description explains when to use each action: 'remove' for a single resource (requiring resource_id) and 'clear' for all cached data. While it does not explicitly contrast with sibling tools (e.g., refresh_cache), the self-contained guidance is sufficient for correct invocation within the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral details like ranking and optional filters, but lacks info on authentication or rate limits.
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?
Two sentences and a bullet list of args, all essential and front-loaded with the purpose. No wasted words.
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?
For a read-only listing tool with existing output schema, the description covers purpose, parameters, and sufficient behavior. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully compensates for 0% schema coverage by explaining each parameter's purpose, defaults, and a hint for higher limit values.
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?
The description clearly states the verb 'List' and the resource 'top tags/topics' ranked by dataset count, distinguishing it from sibling tools like list_organizations or list_portals.
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?
It implies use when needing top tags, but does not explicitly state when not to use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds valuable behavioral details: results include portal-prefixed IDs, searches fan out to all portals by default, and the portal param narrows scope. It does not mention pagination or performance limits, but given the output schema exists, this is acceptable.
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 well-structured, starting with the primary action, then result format and workflow, then parameter explanations in a clean list. Every sentence adds value, and there is no redundancy or 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?
Given the output schema exists and annotations are present, the description covers all critical context: purpose, result unit, workflow integration, default behavior, and all parameter semantics. It is complete for an AI agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides meaningful descriptions for all 7 parameters, including allowed values (e.g., 'CSV', 'JSON') and clarifications like limit being per portal (1-50). This exceeds what the bare schema offers.
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?
The description clearly states the tool searches for datasets across three named open data portals, providing a specific verb and resource. It distinguishes itself from sibling tools like get_dataset_info and download_resource by explaining how the results (portal-prefixed IDs) are used in subsequent steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides when to use this tool (searching), how to use the results (with get_dataset_info, download_resource, get_resource_schema), and when to narrow with the portal param. It also indicates default behavior and provides workflow context, leaving no ambiguity about usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; description adds that queries are read-only (SELECT only), mentions rate limits, and explains the remote API nature, providing 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear note, example, and argument breakdown; every sentence serves a purpose without wasted words.
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?
Given the tool's complexity (SQL query, remote API, rate limits, multiple parameters), the description covers usage, constraints, parameter details, and provides an example, making it fully actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description fully explains the sql parameter (read-only, SELECT only) and portal parameter (default 'ontario', required because SQL embeds resource IDs), adding significant meaning over the schema.
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?
The description clearly states the tool runs SQL queries against the CKAN Datastore, specifies it's remote, and distinguishes from sibling tools by recommending alternatives for repeated queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (quick one-off queries) and when not to (repeated queries should use download_resource + query_cached), and provides an example of how to construct queries.
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:

[![ontario-data-mcp MCP server](https://glama.ai/mcp/servers/sprine/ontario-data-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sprine/ontario-data-mcp)

Score Badge

Copy to your README.md:

[![ontario-data-mcp MCP server](https://glama.ai/mcp/servers/sprine/ontario-data-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sprine/ontario-data-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/sprine/ontario-data-mcp'

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