MapleStats MCP

Plan query

plan_query

Read-onlyIdempotent

Plan which Canadian data sources answer a multi-agency question: identify topics, order tools, local portals, and caveats before running steps.

Instructions

Plan which sources answer a question that may span several agencies.

Use for: the first call on a substantive question ("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; 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

TableJSON Schema

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

Output Schema

TableJSON 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.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.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is low. The description still adds real behavioural detail beyond them: it is offline, calls no external API, matches against this server's source map, and returns an ordering of tools plus caveats.

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?

Core purpose and the use/use-instead guidance are front-loaded in the first two paragraphs; nothing essential is buried. The bilingual keyword lists at the end are retrieval scaffolding rather than prose and pad the definition somewhat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the return values need not be fully documented, and the description still summarises what comes back (topics, ordered tools, local portals, caveats). Combined with rich annotations, an agent has everything needed to call it correctly; only the trailing keyword blocks are surplus.

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 compensate. It explains lang fully (fr localises labels, purposes, caveats and guidance while tool and argument names stay unchanged), and 'question' is self-evident from the example given. The lang explanation is the meaningful addition.

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 (plan) and resource (which sources answer a question), and scopes it as cross-agency/cross-source. It distinguishes itself from both siblings by contrast: call_tool runs the plan's steps and search_tools finds a single tool.

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?

Explicitly says when to use it ('the first call on a substantive question', with a concrete example) and when not to ('Use search_tools instead to find a single tool for a narrow, single-source need'). It also hands off downstream behaviour to call_tool.

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

Deploy Server