Statistics Canada MCP Server

get_sdmx_vector_data

Read-only

Fetch time-series observations for a single StatCan vector via SDMX REST.

Simpler alternative to get_sdmx_data when you already know the vectorId. Use get_series_info (productId + coordinate) to find vectorIds.

Time filtering (use one or the other, not both): lastNObservations=5 → last 5 periods startPeriod="2020-01" → from Jan 2020 (monthly); "2020" for annual endPeriod="2023-12" → up to Dec 2023

LIMITATION: StatCan rejects combining lastNObservations with startPeriod/endPeriod (returns 406).

Output has the same shape as get_sdmx_data: one entry in "series" with its constant fields once, then "observations" as [period, value] pairs.

Growth, percent change or averages? Use query_sdmx instead of computing by hand.

IMPORTANT: In your final response to the user, you MUST cite the source of your data. This means including the _sdmx_url and vectorId in your response.

Input Schema

Name	Required	Description
`vectorId`	Yes
`endPeriod`	No	End period in YYYY or YYYY-MM format.
`startPeriod`	No	Start period in YYYY or YYYY-MM format.
`lastNObservations`	No	Return only the last N observations (e.g. 5 for last 5 periods).

Output Schema

Name	Required	Description
`series`	Yes	Observations grouped by series.
`_message`	No	Truncation guidance, when truncated.
`_sdmx_url`	Yes	SDMX request URL — cite as the data source.
`row_count`	Yes	Total observations returned by StatCan (before truncation).
`_truncated`	Yes	True if observations were capped at 500.
`series_count`	Yes	Number of series in `series`.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 26, 2026

addedOutput schema / $defs

Added value: +{
+  "SDMXSeries": {
+    "additionalProperties": true,
+    "description": "One series: its constant fields (dimension labels, VECTOR_ID, UOM, ...) once.",
+    "properties": {
+      "_series_key": {
+        "description": "Dot-separated SDMX key of this series.",
+        "title": "Series Key",
+        "type": "string"
+      },
+      "observations": {
+        "description": "[period, value] pairs; value is a number or null (suppressed). Observations with their own attributes add a third element {field: label}.",
+        "items": {
+          "items": {},
+          "type": "array"
+        },
+        "title": "Observations",
+        "type": "array"
+      }
+    },
+    "required": [
+      "_series_key",
+      "observations"
+    ],
+    "title": "SDMXSeries",
+    "type": "object"
+  }
+}

changedOutput schema / properties / _truncated / description

Previous value: -"True if data was capped at 500 rows."New value: +"True if observations were capped at 500."

removedOutput schema / properties / data

Removed value: -{
-  "description": "Observation rows: dimension columns, period, value, and SDMX attributes.",
-  "items": {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  "title": "Data",
-  "type": "array"
-}

changedOutput schema / properties / row_count / description

Previous value: -"Total rows returned by StatCan (before truncation)."New value: +"Total observations returned by StatCan (before truncation)."

addedOutput schema / properties / series

Added value: +{
+  "description": "Observations grouped by series.",
+  "items": {
+    "$ref": "#/$defs/SDMXSeries"
+  },
+  "title": "Series",
+  "type": "array"
+}

addedOutput schema / properties / series_count

Added value: +{
+  "description": "Number of series in `series`.",
+  "title": "Series Count",
+  "type": "integer"
+}

changedOutput schema / required

Previous value: -[
-  "_sdmx_url",
-  "row_count",
-  "data",
-  "_truncated"
-]New value: +[
+  "_sdmx_url",
+  "row_count",
+  "series_count",
+  "series",
+  "_truncated"
+]

First observedOct 26, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the rest and does: it discloses a concrete failure mode (StatCan returns 406 when lastNObservations is combined with start/endPeriod) and describes the output shape (one 'series' entry with constant fields, then [period, value] observations). It also states a mandatory post-call obligation, citing _sdmx_url and vectorId.

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?

Front-loads purpose and the sibling alternative, then the filter rules, then the limitation — a sensible order. Slightly padded: the output-shape sentence partly duplicates the existing output schema, and the all-caps IMPORTANT citation block is boilerplate that could be tighter.

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 a 4-parameter read-only tool with an output schema and annotations, nothing an agent needs is missing: it knows what it fetches, the constraints on filters, the error to avoid, the response shape, and the citation requirement. Coverage is complete without restating schema fields verbatim.

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 coverage is 75%, and the description fills the meaningful remaining gap: the mutual-exclusion rule between lastNObservations and startPeriod/endPeriod is a hard parameter constraint the schema does not express. It also gives concrete value examples (5 periods, "2020-01" monthly vs "2020" annual) and explains what vectorId actually identifies, including where to get one.

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 and resource (fetch time-series observations for a single StatCan vector) plus the transport (SDMX REST). It immediately differentiates itself from the sibling get_sdmx_data by naming the exact condition that selects it: 'Simpler alternative to get_sdmx_data when you already know the vectorId.'

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?

Explicit routing in both directions: use get_series_info (productId + coordinate) to obtain vectorIds, use get_sdmx_data when you don't already have one, and use query_sdmx for growth/percent change/averages. It also gives the when-not for the time filters (don't combine lastNObservations with startPeriod/endPeriod).

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

All Statistics Canada MCP Server 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.