MapleStats MCP

Run a Canadian data tool

call_tool

Read-onlyIdempotent

Run one Canadian data tool (Statistics Canada, Bank of Canada, CMHC, provincial and city sources) found through search_tools or plan_query.

Use for: executing a tool by exact name with arguments that match the arguments search_tools returned for it. Data tools read public sources (StatCan, Bank of Canada, open-data portals). reproduce_workbook can save an Excel file on a local stdio server; hosted exports return base64. Returns that tool's result. detail is "brief" by default: values, periods, units and scale, members, the citation, status flags, caveats and limits, with a list of six or more rows written as CSV text ({"format": "csv", "csv": ...}), and provenance cut to source, URL, licence and caveats. Pass detail="full" for every field and the full provenance block (query time, freshness, schema), with rows as JSON objects. Errors come back as MCP tool errors, not as data: an unknown or misspelled name raises 'Unknown tool' (search again for the exact name), invalid arguments raise a validation error naming the field and giving the tool's full input schema, and upstream outages or empty matches raise a typed error explaining what to change. search_tools, call_tool and plan_query cannot be called through it; call them directly. Tool calls are subject to the server's timeout (MAPLE_TOOL_TIMEOUT_SECONDS, default 120).

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": {
      "name": "<name>"
    },
    "name": "call_tool"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Exact tool name as returned by search_tools or plan_query, e.g. 'boc_get_observations'.
`detail`	No	'brief' (the default): values, units, citation, caveats and limits, long row lists as CSV. 'full': every field and the full provenance.
`arguments`	No	Object matching that tool's arguments from search_tools. Omit or pass {} for a tool with no required parameters.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

changedInput schema / properties / arguments / description

Previous value: -"Object matching that tool's inputSchema from search_tools. Omit or pass {} for a tool with no required parameters."New value: +"Object matching that tool's arguments from search_tools. Omit or pass {} for a tool with no required parameters."

Changed1 schema field changedNov 9, 2026

addedInput schema / properties / detail

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "brief",
+        "full"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "'brief' (the default): values, units, citation, caveats and limits, long row lists as CSV. 'full': every field and the full provenance."
+}

First observedOct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, open-world, non-destructive, so the safety profile is covered; the description goes further by disclosing the default `detail` payload shape, the base64 behavior for hosted exports versus local file saves for reproduce_workbook, the three distinct error classes ('Unknown tool', field-naming validation errors, typed upstream errors), and the server timeout (MAPLE_TOOL_TIMEOUT_SECONDS, default 120). That is real behavioral context an agent cannot get from annotations or schema.

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-loaded with purpose then a 'Use for' block, followed by return-shape and error-behavior paragraphs in a logical order. It is information-dense rather than padded, but the error-mode sentence is a long run-on and some return-shape detail repeats what the `detail` schema description already says, costing a bit of tightness.

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?

There is no output schema, so the description must carry the full burden of the return value — and it does, covering brief versus full payloads, row serialization format, provenance truncation, error classes, and timeout. For a dynamic wrapper dispatching to arbitrary downstream tools, this is as complete as a description can reasonably be.

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 earns extra by explaining what 'full' actually changes — every field plus the full provenance block (query time, freshness, schema) and rows as JSON objects rather than the CSV envelope ({"format": "csv", "csv": ...}) used in brief mode. It also clarifies that `arguments` must mirror the target tool's schema and may be omitted or {} when no required parameters exist, though it adds no further detail on individual `name` patterns beyond one example.

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?

Names a specific verb and resource ('Run one Canadian data tool') and enumerates the source domains it covers (StatCan, Bank of Canada, CMHC, provincial and city sources). It explicitly distinguishes itself from the meta-tools that produce tool names (search_tools, plan_query), so an agent knows this is the execution step, not the discovery step.

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?

'Use for: executing a tool by exact name with arguments that match the arguments search_tools returned for it' states the prerequisite and the argument provenance precisely. It also names exclusions — search_tools, call_tool and plan_query cannot be called through it and must be called directly — which is exactly the kind of recursion trap a wrapper tool needs to rule out.

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

All MapleStats MCP 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.