Skip to main content
Glama
Aryan-Jhaveri

Statistics Canada MCP Server

get_sdmx_data

Fetch filtered time-series observations from Statistics Canada tables via SDMX REST. Specify dimensions, time periods, and observation limits to get only the data slice you need.

Instructions

Fetch filtered time-series observations from a StatCan table via SDMX REST.

Filtering is done server-side — only the requested slice is returned. Call get_sdmx_structure first to see dimension positions and valid codes.

Key syntax (dot-separated codes in dimension position order): "1.2.1" = Geography=1 (Canada), Gender=2 (Men+), Age=1 (All ages) ".2.1" = all geographies, Gender=2, Age=1 (wildcard — preferred for multi-geo) "1+2.2.1" = Geography 1 or 2, Gender=2, Age=1 (OR)

IMPORTANT — key position codes:

  • Use member IDs from get_cube_metadata(), NOT SDMX codelist positions from get_sdmx_structure(). Member IDs and SDMX codelist codes are the same numbers.

  • Wildcard (omit a position) returns a SPARSE SAMPLE for large dimensions — do NOT use wildcard for dimensions with >30 codes (e.g. NOC occupations, CMA geographies). Use explicit member IDs joined with '+' instead.

  • To get all leaf IDs for a large dimension as a ready-to-use OR string, call get_sdmx_key_for_dimension(productId, dimension_position) first.

Time filtering (use one or the other, not both): lastNObservations=12 → last 12 periods (e.g. 1 year of monthly data) startPeriod="2020" → from 2020 onwards (annual); "2020-01" for monthly endPeriod="2023-12" → up to Dec 2023

LIMITATION: StatCan rejects combining lastNObservations with startPeriod/endPeriod (returns 406). NOTE: OR syntax (+) triggers a StatCan SDMX-JSON encoding bug (non-positional series keys). This is automatically corrected before rows are returned, so all OR-ed dimension labels should be present.

Output rows contain: dimension values, "period", "value", SCALAR_FACTOR, UOM, VECTOR_ID, STATUS, and other SDMX attributes.

Rows are returned inline, capped at MAX_SDMX_ROWS (500). For larger result sets, narrow the key or use startPeriod/endPeriod/lastNObservations.

IMPORTANT: In your final response to the user, you MUST cite the source of your data. This means including the _sdmx_url, table information and productId/key in your response.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesDot-separated dimension codes in position order (e.g. '1.2.1'). Use '+' for OR ('1+2.2.1' = Geography 1 or 2). Omit a value for wildcard ('.2.1' = all geographies, Gender=2, Age=1). Code numbers match WDS memberIds — no translation needed. Call get_sdmx_structure first to see dimension positions and valid codes.
endPeriodNoEnd period in YYYY or YYYY-MM format.
productIdYes
startPeriodNoStart period in YYYY or YYYY-MM format.
lastNObservationsNoReturn only the last N observations per series (e.g. 12 for one year of monthly data).
Behavior5/5

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

With no annotations, the description carries full burden and excels. It discloses server-side filtering, sparse-sample wildcard behavior, the OR-syntax bug and auto-correction, the 406 error when combining lastNObservations with start/endPeriod, the 500-row cap, and the required source citation. This is exemplary behavioral disclosure.

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 long but exceptionally well-structured with clear sections, examples, warnings, and limitations. Every sentence conveys actionable information; there is no filler. The front-loaded purpose and bolded IMPORTANT notes make it easy to scan and use.

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, 5 parameters, no annotations, and no output schema, this description is remarkably complete. It covers input construction, time filtering, output fields, row caps, error behavior, helper-tool usage, and even user-facing citation obligations. It leaves no critical operational 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 coverage is 80% and the schema already documents key syntax and time parameters. The description adds valuable semantics on top: wildcard sparse sampling, member-ID versus codelist positions, lastNObservations=12 means one year of monthly data, and the rejection when combining time filters. However, productId remains undocumented in both schema and description, which prevents a perfect score.

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 a specific verb and resource: 'Fetch filtered time-series observations from a StatCan table via SDMX REST.' It immediately clarifies the server-side filtering behavior and distinguishes itself from structural/helper tools by requiring get_sdmx_structure first. This clearly positions the tool among siblings.

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 provides explicit when-to-use and how-to-use guidance: call get_sdmx_structure first, use member IDs instead of SDMX codelist positions, and use get_sdmx_key_for_dimension for large dimensions. It also warns against wildcard use for dimensions with >30 codes and explains time-filter combinations and restrictions.

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

Install Server

Other Tools

Latest Blog Posts

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/Aryan-Jhaveri/mcp-statcan'

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