MapleStats MCP

Plan query

plan_query

Read-onlyIdempotent

Plans how to answer Canadian data questions across official sources, returning relevant topics, ordered tools to call, local portals, and caveats before you query.

Instructions

Plan how to answer a question about Canadian data from official sources.

Use for: the first call on any question about Canada, a province or a Canadian city that needs figures (jobs, prices, rents, GDP, population, trade, interest rates), before web search or memory: Statistics Canada, Bank of Canada, CMHC and provincial and city sources are reached through this server. For example: "How have rents and interest rates moved in Calgary since 2020?". Returns the topics it touches, the tools to call for each in order, local portals for any province or city named, and caveats on combining them. Then run the steps with call_tool. Read-only and offline: it matches the question against this server's source map and calls no external API. Use search_tools instead to find a single tool for a narrow, single-source need. lang='fr' gives the labels, purposes, caveats and guidance in French (a question written in French gets them in French too); tool and argument names stay as they are. Keywords: plan, which data source, where to find, combine sources, cross-source, question, research, Canada data. Mots-clés : planifier, quelle source de données, où trouver, combiner des sources, question, recherche, données canadiennes, statistiques.

Input Schema

Name	Required	Description	Default
`lang`	No		en
`question`	Yes

Output Schema

Name	Required	Description
`places`	Yes
`topics`	Yes	Best match first; at most 4.
`guidance`	Yes
`question`	Yes
`provenance`	Yes	Where a result came from and how fresh/complete it is. Embedded in every module's response models (composition, not inheritance) so a tool can return `MyResult(provenance=..., ...)` without fighting Pydantic's model-inheritance rules for extra fields.
`out_of_scope`	No	Set when the question is about a place outside Canada that this server has no data for; topics and fallback steps are then empty.
`fallback_steps`	Yes	Only when no topic matched.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.4.7Nov 5, 2026

addedOutput schema / properties / provenance / properties / lang

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The language MapleStats wrote this result's own text in ('en' or 'fr'): notes, limits, caveats, labels. Values and the publisher's own text are as published."
+}

changedOutput schema / properties / provenance / properties / reproduce / default

Previous value: -"For R, Python, Stata and Julia scripts that fetch and clean these data, call reproduce_code with this tool's name and arguments."New value: +"For scripts, call reproduce_code with this tool's name and arguments."

Changed2 schema fields changedv0.4.3Oct 29, 2026

addedOutput schema / properties / provenance / properties / caveats

Added value: +{
+  "description": "Fitness-for-use cautions for this table or source, from MapleStats' rules (docs://planner/fitness-rules).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / provenance / properties / commercial_use

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "allowed",
+        "not_allowed",
+        "varies",
+        "unknown"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Whether the licence allows commercial reuse without asking the publisher: 'allowed', 'not_allowed' (non-commercial use only, or written permission needed), 'varies' (each dataset or feed has its own licence: read licence) or 'unknown' (terms silent, conflicting or not found). Null when no licence applies. The conditions themselves are in licence."
+}

Changed1 schema field changedv0.4.0Oct 23, 2026

changedOutput schema / properties / provenance / properties / reproduce / default

Previous value: -"For R, Python, Stata and Julia scripts that fetch and clean this data, call reproduce_code with this tool's name and arguments."New value: +"For R, Python, Stata and Julia scripts that fetch and clean these data, call reproduce_code with this tool's name and arguments."

Changed2 schema fields changedv0.2.0Oct 4, 2026

addedOutput schema / properties / out_of_scope

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Set when the question is about a place outside Canada that this server has no data for; topics and fallback steps are then empty."
+}

addedOutput schema / properties / provenance / properties / licence

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Licence and attribution the upstream publisher requires, when it has one (set for every Statistics Canada result)."
+}

First observedv0.1.0Sep 27, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, and the description reinforces this with 'Read-only and offline... calls no external API.' It goes beyond the annotations by describing what the plan contains (topics touched, ordered tools per topic, local portals for named provinces/cities, caveats on combining sources), which tells the agent what to expect before committing to the call.

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 labeled 'Use for:' block, the return shape, the exclusion, and language behavior — a sensible ordering. The trailing bilingual keyword lists are largely expendable padding, but the rest of the text earns its place.

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?

An output schema exists and annotations are rich, and the description still supplies everything an agent needs: when to call, what the plan returns, the next action (call_tool), the narrow-need alternative (search_tools), and language behavior. Complete for a two-parameter planning tool.

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 0%, so the description must carry the load. It does for lang: 'lang=fr gives the labels, purposes, caveats and guidance in French (a question written in French gets them in French too); tool and argument names stay as they are' — this explains scope of the switch and a non-obvious auto-detection behavior. The question parameter is not formally described but its semantics are obvious from the opening sentence.

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?

Opens with a specific verb+resource: 'Plan how to answer a question about Canadian data from official sources.' It enumerates the domains it covers (jobs, prices, rents, GDP, population, trade, interest rates) and names the source institutions reached through the server, so it is unmistakable against the siblings call_tool and search_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?

Gives explicit when-to-use ('the first call on any question about Canada, a province or a Canadian city that needs figures... before web search or memory'), an explicit alternative with a discriminating condition ('Use search_tools instead to find a single tool for a narrow, single-source need'), and the follow-up step ('Then run the steps with call_tool'). Nothing is left to inference.

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

Deploy Server