Statistics Canada MCP Server

get_cube_metadata

Retrieve detailed metadata for a Statistics Canada data cube by ProductId, including dimensions, titles, and date ranges. Summaries are compact by default; set summary=False for full raw details.

Instructions

Retrieves detailed metadata for a specific data table/cube using its ProductId. Includes dimension info, titles, date ranges, codes, etc. Disables SSL Verification. Corresponds to: POST /getCubeMetadata

Start with summary=True (default). The summary strips noise (French translations, archive codes, footnotes) and shows only 3 sample members per dimension with _next_steps guidance. Safe for all context window sizes. Set summary=False only if you need the full raw member list or all API fields.

To browse dimension codes for get_sdmx_data key construction, use get_sdmx_structure. To resolve a coordinate to a vectorId, use get_series_info.

Returns: Dict[str, Any]: The metadata object for the specified cube on success. Raises: httpx.HTTPStatusError: If the API returns an error status code. ValueError: If the API response format is unexpected or status is not SUCCESS. Exception: For other network or unexpected errors.

IMPORTANT: In your final response to the user, you MUST cite the source of your data. For cubes, this means including the ProductId (pid) and the Title.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "productId": "<productId>"
    },
    "name": "get_cube_metadata"
  }
}

Input Schema

Name	Required	Description	Default
`summary`	No	When True (default), returns a compact summary: essential cube metadata, dimension names, 3 sample members per dimension, and _next_steps guidance. Set to False only when you need the full raw member list or all API fields.
`productId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.7.15Aug 6, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses a notable behavior: 'Disables SSL Verification.' It also explains the summary mode's behavior (strips French translations, shows 3 sample members, adds _next_steps) and explicitly warns about safe context window sizes. It lists exceptions and even adds a mandatory citation instruction. While it could explicitly state read-only intent, the retriever verb and non-mutating nature are clear enough.

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 reasonably sized for the tool's complexity and front-loaded with the primary purpose. Each section (endpoint mapping, summary guidance, alternatives, return/raises, citation note) adds value. It is slightly verbose with repetitive emphasis (e.g., summary=True repeated), but overall well-organized and 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 no output schema and no annotations, the description compensates well. It describes the return type (Dict[str, Any]), explains the summary vs. full modes, lists exceptions, and provides situational guidance (e.g., safe for all context window sizes). The mention of _next_steps guidance and citation requirements gives operational completeness. Nothing essential is missing for an agent to invoke and use the tool correctly.

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 only 50% (summary is described, productId is not). The description goes beyond the schema by thoroughly explaining the summary parameter: 'strips noise (French translations, archive codes, footnotes) and shows only 3 sample members per dimension with _next_steps guidance.' The productId parameter is only mentioned as 'using its ProductId', but the endpoint mapping and citation note ('including the ProductId (pid) and the Title') give additional context. Given the strong added meaning for summary, this is above baseline.

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 clear statement of purpose: 'Retrieves detailed metadata for a specific data table/cube using its ProductId.' It lists specific content (dimension info, titles, date ranges, codes) and maps to a concrete endpoint (POST /getCubeMetadata). Sibling differentiation is also explicit via references to get_sdmx_structure and get_series_info, making it easy to distinguish from related tools.

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 guidance: 'Start with summary=True (default)... Set summary=False only if you need the full raw member list or all API fields.' It also names alternatives for adjacent tasks: 'To browse dimension codes... use get_sdmx_structure. To resolve a coordinate to a vectorId, use get_series_info.' This covers both usage context and exclusions.

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