Statcan

Statcan List Cubes

statcan_list_cubes

Read-onlyIdempotent

List available StatCan cubes (tables) — lean: productId + title (en/fr) + CANSIM id + dimension count + release date. Use the productId with statcan_cube_metadata / statcan_cube_data. StatCan has ~8,000 cubes and its endpoint has no paging of its own, so this tool pages for you: pass title to search by name (recommended — it is the fast way to the handful you want), or walk page. Default 200 per page; has_more tells you whether more exist.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "statcan_list_cubes"
  }
}

Input Schema

Name	Required	Description
`page`	No	Page number, 1-based (default 1).
`limit`	No	Cubes per page (1-500, default 200).
`title`	No	Case-insensitive substring match against the English and French cube titles, e.g. "egg" or "population". Applied to the cubes scanned on this page.

Output Schema

Name	Required	Description
`note`	No	Present when the scan was truncated: says what was scanned and how to narrow
`page`	Yes	1-based page number returned
`count`	Yes	Cubes returned on THIS page (not the catalogue total -- StatCan's endpoint has no paging, so this tool streams and pages; use has_more/next_page)
`cubes`	Yes	List of available cubes
`limit`	Yes	Cubes per page (1-500, default 200)
`licence`	No	Statistics Canada Open Licence
`scanned`	No	Cubes read off the upstream stream before stopping -- the bound that keeps this call from holding StatCan's whole 8 MB array in memory
`has_more`	Yes	True when more cubes exist beyond this page
`next_page`	No	Next page number, or null at the end
`title_filter`	No	The lower-cased title substring applied, or null
`scan_truncated`	No	True when the read stopped at the cap rather than the end of the upstream array, so a short page is OUR ceiling and not proof the list ended
`upstream_bytes_read`	No	Bytes actually pulled from StatCan WDS for this call

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedOct 23, 2026

addedInput schema / properties / limit

Added value: +{
+  "description": "Cubes per page (1-500, default 200).",
+  "type": "number"
+}

addedInput schema / properties / page

Added value: +{
+  "description": "Page number, 1-based (default 1).",
+  "type": "number"
+}

addedInput schema / properties / title

Added value: +{
+  "description": "Case-insensitive substring match against the English and French cube titles, e.g. \"egg\" or \"population\". Applied to the cubes scanned on this page.",
+  "type": "string"
+}

changedOutput schema / properties / count / description

Previous value: -"Total number of cubes"New value: +"Cubes returned on THIS page (not the catalogue total -- StatCan's endpoint has no paging, so this tool streams and pages; use has_more/next_page)"

addedOutput schema / properties / has_more

Added value: +{
+  "description": "True when more cubes exist beyond this page",
+  "type": "boolean"
+}

addedOutput schema / properties / licence

Added value: +{
+  "description": "Statistics Canada Open Licence",
+  "type": "string"
+}

addedOutput schema / properties / limit

Added value: +{
+  "description": "Cubes per page (1-500, default 200)",
+  "type": "number"
+}

addedOutput schema / properties / next_page

Added value: +{
+  "description": "Next page number, or null at the end",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / note

Added value: +{
+  "description": "Present when the scan was truncated: says what was scanned and how to narrow",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / page

Added value: +{
+  "description": "1-based page number returned",
+  "type": "number"
+}

addedOutput schema / properties / scan_truncated

Added value: +{
+  "description": "True when the read stopped at the cap rather than the end of the upstream array, so a short page is OUR ceiling and not proof the list ended",
+  "type": "boolean"
+}

addedOutput schema / properties / scanned

Added value: +{
+  "description": "Cubes read off the upstream stream before stopping -- the bound that keeps this call from holding StatCan's whole 8 MB array in memory",
+  "type": "number"
+}

addedOutput schema / properties / title_filter

Added value: +{
+  "description": "The lower-cased title substring applied, or null",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / upstream_bytes_read

Added value: +{
+  "description": "Bytes actually pulled from StatCan WDS for this call",
+  "type": "number"
+}

changedOutput schema / required

Previous value: -[
-  "count",
-  "cubes"
-]New value: +[
+  "count",
+  "page",
+  "limit",
+  "has_more",
+  "cubes"
+]

AddedJun 20, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds non-obvious operational context: ~8,000 cubes, no native endpoint paging so the tool pages for you, default 200 per page, and `has_more` as the continuation signal. It does not mention auth or rate-limit behavior, so it stops short of a 5.

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?

Front-loaded with purpose and return shape, then usage, then paging behavior — no filler sentences. The em-dash fragment 'lean: productId + title...' compresses the return contract efficiently rather than padding it.

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?

Despite 3 optional params and a large open corpus, the description covers what an agent must know to call it correctly: search-vs-page strategy, page size, and the `has_more` continuation signal. An output schema exists, so return values need no further explanation.

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 100%, so the baseline is 3; the description goes further by labelling `title` as the recommended fast path (substring match already documented) and by explaining the paging contract (default 200, `has_more`) that governs `page`/`limit` usage. That is genuine added meaning over the schema text.

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?

States a specific verb+resource ('List available StatCan cubes (tables)') and immediately enumerates the lean return shape (productId, title en/fr, CANSIM id, dimension count, release date). It also distinguishes itself from statcan_cube_metadata and statcan_cube_data by naming the downstream tools that consume the productId.

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 routes the agent: use productId with statcan_cube_metadata / statcan_cube_data, and prefer `title` search ('recommended — it is the fast way to the handful you want') over walking `page`. Covers both the lookup path and the enumeration path with the condition that selects each.

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

All Statcan tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.