Skip to main content
Glama

Nova Scotia Data Explorer

by io.github.SevaSk

Query a Nova Scotia Open Dataset

query_dataset

Run a SoQL query against a Nova Scotia Open Data dataset. SoQL is SQL-like.

Key clauses (combine with &): $select=col1,col2 — choose columns $where=field='value' — filter rows (use single quotes for strings) $where=field like '%val%' — partial match $order=field DESC — sort $limit=50 — row count (default 25, max 50000) $offset=50 — pagination $group=field — group by (use with aggregate functions) $q=search term — full-text search

Aggregates: count(*), sum(col), avg(col), min(col), max(col)

Examples: $where=year='2024'&$order=total DESC&$limit=10 $select=department,count()&$group=department&$order=count() DESC $where=area like '%Halifax%'&$limit=5

Always call get_dataset_metadata first to find exact field names.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
soqlNoSoQL query string. Multiple clauses joined with '&'. String values in $where must use single quotes: field='value'. Do NOT URL-encode — pass the raw string.
limitNoMax rows to return (1–1000, default 25). Ignored if $limit is in soql.
dataset_idYes8-character Socrata dataset identifier (e.g. '3nka-59nz')

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and delivers: default/maximum row counts, pagination via $offset, grouping, aggregates, and full-text search. It clearly implies a non-destructive query operation, though it does not describe the response shape or error 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?

Despite the length, every line contributes: the opening sentence states the purpose, clauses are grouped in a compact list, and three concrete examples illustrate usage. The front-loaded structure makes the syntax reference scannable.

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?

The description is rich enough for a complex query tool with no output schema, covering syntax, limits, aggregation, and prerequisite metadata call. However, it does not mention likely failure modes or response format, leaving a small completeness gap.

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 already covers all three parameters with 100% coverage, so baseline is 3; description adds a full SoQL clause reference and examples that clarify how to combine parameters and construct queries. It stops short of 5 because the parameter-specific descriptions in the schema already carry most of the semantics.

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 opens with 'Run a SoQL query against a Nova Scotia Open Data dataset'—a specific verb and resource. This clearly differentiates it from siblings like get_dataset_metadata, list_categories, and search_datasets.

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 explicit instruction to 'Always call get_dataset_metadata first to find exact field names,' establishing the intended workflow. It also documents when to use each SoQL clause, but does not explicitly contrast with sibling search tools, stopping short of a 5.

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

All Nova Scotia Data Explorer toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: listing categories, searching for datasets, retrieving metadata for a specific dataset, and querying a specific dataset. There is no overlap or ambiguity between them, and the workflow is well-defined.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores: get_dataset_metadata, list_categories, query_dataset, search_datasets. The verbs (get, list, query, search) are distinct and match each tool's function.

Tool Count5/5

Four tools is well-scoped for a data explorer server. Each tool fills a necessary step in the workflow (discover → search → metadata → query), with no redundancy or unnecessary extras.

Completeness5/5

The tool set covers the full exploration lifecycle for open data: discovering categories, searching datasets, retrieving schema metadata, and running queries. There are no obvious gaps; the tools are designed to work together seamlessly.

Resources