MapleStats MCP
MapleStats MCP is a single MCP server for typed, sourced access to Canadian open data — letting agents plan, find, and run data queries across dozens of federal, provincial, territorial, municipal, and international sources.
Plan multi-source research:
plan_querymaps a plain-language question (e.g. rents + interest rates in Calgary) to an ordered set of tools, local portals, and caveats.Discover the right tool:
search_toolsdoes plain-language (English/French) search across 380 tools in 75 modules, returning full input schemas.Execute data tools:
call_toolruns any discovered tool and returns typed results with a provenance block (source, URL, query time, freshness, limits, licence).Statistics Canada access: WDS tables, SDMX spaces, Census Profiles 2001–2021, public use microdata, CIMT trade, LODE, The Daily, delta files, geography and surveys.
Other Canadian sources: Bank of Canada, CMHC, federal agencies (weather, health, recalls, elections, immigration, energy, etc.), wildland fire, electricity (Ontario/Quebec), Parliament and elected officials, provincial agencies, and municipal/transit open data.
International data: World Bank development indicators and BIS statistics.
Open-data portals: federal, provincial, territorial, and municipal catalogues via CKAN, ArcGIS Hub, and Socrata connectors.
Reproducibility:
reproduce_codegenerates R, Python, Stata, Julia, or Excel Power Query scripts;reproduce_workbookreturns a formatted Excel workbook.Bilingual support: every tool accepts
lang: "en"|"fr", with bilingual docs and prompts.Flexible deployment: use the hosted server (no account/key) or run locally over stdio; optional HTTP hosting with auth, rate limits, caching, and circuit breakers.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MapleStats MCPGet Canada's inflation rate from StatCan and generate Python code to plot it"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MapleStats MCP gives AI agents (Claude, Cursor and any MCP client) typed access to Canadian open data through one server: Statistics Canada (tables, Census, public use microdata), the Bank of Canada, CMHC, federal agencies, and federal, provincial, territorial and municipal open-data portals, in English and French. Every result carries its source.
MapleStats MCP donne aux agents IA un accès structuré aux données ouvertes canadiennes par un seul serveur, en français et en anglais.
Project vision: docs/PROJECT_GUIDE.md.
Source coverage: docs/ROADMAP.md.
Website: https://maplestats.danielstats.io/.
The easiest way: ask your agent
Copy this prompt.
Paste it into Claude Code, Codex, Cursor or any agent that can run commands on your computer.
Restart the agent when it says so, then ask for data.
Connect the MapleStats MCP server to this agent. Follow the setup steps in https://github.com/dsanchezp18/maplestats-mcp
Instructions for the agent doing the setup
The default is the hosted server: nothing to install, no account, no key.
Register this remote (HTTP) MCP server under the name
maplestats:Claude Code:
claude mcp add --transport http --scope user maplestats https://maplestats-mcp.onrender.com/mcpCodex CLI:
codex mcp add maplestats --url https://maplestats-mcp.onrender.com/mcpCursor, Claude Desktop and other
mcpServersclients: add the entry below to the client's config file (Cursor:~/.cursor/mcp.json; Claude Desktop:~/Library/Application Support/Claude/claude_desktop_config.jsonon macOS,%APPDATA%\Claude\claude_desktop_config.jsonon Windows), keeping any servers already there.claude.ai and the Claude phone app: on the web, open Settings → Connectors → Add custom connector, name it
MapleStats, and enterhttps://maplestats-mcp.onrender.com/mcp. Then switch it on from the tools menu in a chat, on the web or in the phone app. Claude asks for approval before each call by default; every tool is read-only, so set them to always allow in the connector's tool permissions.ChatGPT (web): turn on Settings → Security and login → Developer mode, then create a developer-mode app for a remote MCP server with the same address and No Authentication. Every tool is read-only, so ChatGPT should not ask to confirm calls. OpenAI documents this feature for the web.
A whole organization: on Claude Team or Enterprise, an Owner adds it once under Organization settings → Connectors → Add custom connector, and each member then connects it. On ChatGPT Business, Enterprise or Edu, an admin turns on Developer mode (Workspace Settings → Permissions & Roles → Connected Data), creates the app, and publishes it (Workspace settings → Apps → Drafts → Publish). The hosted server is shared and limits each client to 60 requests a minute, so a large organization should run its own copy.
VS Code: the same entry under a
serverskey, with"type": "http", in.vscode/mcp.json.
{ "mcpServers": { "maplestats": { "url": "https://maplestats-mcp.onrender.com/mcp" } } }Tell the user to restart or reload the client, then check that the
search_toolstool is listed.Only if the client cannot use remote servers, or the user wants the microdata tabulation tool or everything kept on their own machine, run it locally instead:
claude mcp add --scope user maplestats -- uvx maplestats-mcp(needs uv), or the equivalentuvx maplestats-mcpentry for other clients (see Install).
The first request after a quiet spell can take up to a minute; if your client reports the server as failed, retry a minute later. Each client gets 60 requests a minute, and the microdata tabulation tool is switched off there. Your agent's tool calls (a search phrase, a table number) reach the server and its host, Render. The code keeps no log of them, but its in-memory cache can hold a search phrase or filter in a key or a response until the entry expires or the server restarts. Check Render's terms and privacy policy; for full privacy, run it locally. What it logs: FAQ. Other clients: the Connect page.
Related MCP server: Données Québec MCP
Install locally (optional)
Prefer to run it on your machine? It works over stdio with no account or key.
uvx maplestats-mcp # run without installing
uv tool install maplestats-mcp # or install the command once (pip works too)
uv tool upgrade maplestats-mcp # updateFor the development version: uv tool install git+https://github.com/dsanchezp18/maplestats-mcp.git.
If you installed the command, use "command": "maplestats-mcp" with no
args in the JSON above. On Windows, make sure the directory where uv
installs tools is on PATH, and restart the client afterwards.
Using it
Tools are found through search rather than listed flat: call
search_tools with a plain-language query (English or French), then
call_tool with the name it returns.
{"name": "search_tools", "arguments": {"query": "consumer price index"}}
{"name": "call_tool", "arguments": {"name": "wds_search_cubes", "arguments": {"query": "consumer price index"}}}plan_query turns a question into an ordered, multi-source plan, and
reproduce_code writes the R, Python, Stata or Julia script (or an Excel
Power Query) that fetches the same data straight from the source;
reproduce_workbook returns the rows as a formatted Excel workbook. Every tool accepts lang: "en"|"fr";
some sources only publish English content (for example Yukon's CKAN portal,
the World Bank's indicator definitions and the PMPRB), so there lang
changes the labels MapleStats adds, not the source's own text. Every response
has a provenance block: source, URL, query time, freshness and limits.
docs://catalogue describes every module in both languages. The guided
prompts take lang too, and each docs://<module>/... resource has a French
twin at docs://<module>/fr/... (for example docs://statcan/fr/pieges).
To call the sources from Python without MCP, see docs/library.md.
What to watch for
MapleStats retrieves data directly from the original sources and returns
values as published. When a result is trimmed, scaled, cleaned or computed,
it says so in its provenance block or its notes; series values come
unscaled, with the scale factor beside them. When a source is down or blocks
the request, the tool returns an error, not a silent gap or a substitute
value.
The risk is in the use. An AI assistant can pick the wrong table, geography
or reference period, and the answers, summaries and analysis it writes are
AI-generated and can contain errors. For anything you would publish,
spot-check a few figures against the source's own site and use
reproduce_code to fetch them again outside the assistant. Publishers revise
their figures, so a value retrieved today can differ from an earlier one.
Each dataset keeps its own licence and attribution terms, shown in the
result's provenance; credit the publisher, not MapleStats. MapleStats is an
independent project, not affiliated with or endorsed by Statistics Canada,
the Bank of Canada, CMHC or any other data provider. It is provided as is,
depends on upstream services that can change or go offline, and is not
professional, legal or financial advice. Parts of the code and tests were
written with AI assistance; the discovery benchmark's questions were
written by one AI session and reviewed by a second, independent one, not yet
by a person
(tests/discovery_benchmark/REVIEW.md).
What it covers
380 tools in 75 modules. Run docs://catalogue for the full, bilingual list.
Area | Tool prefixes | Covers |
Statistics Canada |
| Tables and series, the extra SDMX spaces (energy information, shared data), classifications, Census Profiles 2001–2021, public use microdata (codebooks, weighted tables), merchandise trade by commodity (CIMT), open databases (LODE), The Daily, delta files, indicators, surveys, census geography |
Bank of Canada |
| Valet series, groups, observations |
CMHC |
| Housing Market Information Portal and Excel data tables |
Federal agencies |
| Weather, climate and gridded climate projections, pollutant releases and emissions (NPRI, GHGRP, NAPS), corporations and IP, regulations, recalls, dairy, animal disease, consumer banking, federal and provincial fiscal tables, health, drugs, natural health products, medical devices, adverse reactions, pesticides, spending, energy, mineral production, oceans, grain, forestry, immigration, border wait times, customs tariff rates, budgets, mergers, elections, earthquakes, university-library data tables, First Nation profiles, registered population and drinking water advisories |
Wildland fire |
| NRCan's Canadian Wildland Fire Information System (satellite hotspots, fire danger, weather stations), burned areas, and Alberta Wildfire's live fire status |
Electricity |
| IESO (Ontario) demand, generation and prices; Hydro-Québec demand, generation and trade (CC BY-NC 4.0: credit Hydro-Québec, non-commercial use only); Ontario Energy Board datasets |
Parliament and elected officials |
| MPs and their roles, party standings, Cabinet, Senate votes; elected officials and districts for a postal code via Open North's Represent (unofficial) |
Provincial agencies |
| Alberta Energy Regulator, BC Geographic Warehouse, BC Stats Excel tables, BC environmental monitoring (air quality, snow, groundwater, streamflow), BC lobbyists registry, DriveBC road events, Alberta Economic Dashboard, Open Alberta files, Institut de la statistique du Québec, the Newfoundland and Labrador, Yukon and Northwest Territories statistics bureaus, provincial general election results (Quebec, Alberta, British Columbia, Saskatchewan, Manitoba), Ontario's municipal Financial Information Return (every schedule of every municipality, 2000 on) |
Housing (links only) |
| Links, release timing and terms for CREA's MLS® Home Price Index; no values, because CREA's terms allow private, non-commercial analysis only |
International |
| World Bank World Development Indicators for Canada and peer countries (CC BY 4.0); Bank for International Settlements statistics: policy rates, debt service ratios, credit, house prices, banking and payment statistics (free reuse with citation) |
Open-data portals |
| Federal, provincial, territorial and municipal catalogues ( |
Other municipal |
| Vancouver, Newfoundland and Labrador, Edmonton police, transit and water quality |
Transit schedules |
| Static GTFS timetables of the STM (buses), OC Transpo, Calgary Transit, VIA Rail, GO Transit, UP Express, the BC Transit systems and the Quebec networks listed on Données Québec (exo, RTC, STL, STS and others), plus further agencies from Statistics Canada's 2025 Canadian Public Transit Network Database: stops, routes, scheduled departures, frequency by hour |
Other federal series (CRA, OSFI, ISED insolvency) are ordinary
open.canada.ca datasets, reachable with
ckan_search_datasets(portal="federal", fq="organization:<org>").
Not covered: CAPP's Statistics Handbook, Petrinex and Payments Canada were not built, because their terms or download hosts do not permit automated access. CanadaBuys, OpenParliament.ca and the Toronto Transit Commission's own schedule download were removed for the same reason (the TTC schedule is still served from Statistics Canada's national transit database), and the Saskatchewan GeoHub portal was removed. The 2006-2016 census data tables and the 2016 Census Profile service were removed because Statistics Canada's www12 host answers automated clients with a bot challenge, 503 errors or timeouts (the 2021 profile and the WDS tables remain). Justice Laws (federal statutes and regulations) is out of scope, because legislation text is not data this server carries, and the Saskatchewan Bureau of Statistics' Provincial Economic Accounts were not built: they are under Crown copyright, for non-commercial reuse only, and the site's terms bar automated access. The roadmap records each decision.
Development
uv sync # install
uv run ruff check src tests # lint
uv run ruff format src tests # format
uv run pyright # type check
uv run pytest # unit tests (mocked, no network).\scripts\verify.ps1 runs that gate plus every scripts/smoke_test*.py
against the live APIs. The website is generated from the tool registry:
uv run python scripts/build_site.py writes build/site/. See
AGENTS.md
for the contributor guide and how to add a source module.
Hosting
MAPLE_TRANSPORT=http MAPLE_HOST=0.0.0.0 MAPLE_PORT=8000 uv run maplestats-mcp
serves HTTP instead of stdio; docker compose up --build does the same in
Docker. Docker is optional and unnecessary on a personal computer. If the
server is exposed beyond your machine, set MAPLE_AUTH_TOKEN and keep
MAPLE_REQUIRE_AUTH=1. GET /health reports uptime and version. GET /stats
is public, needs no token and reports calls per tool name and day, each tool's
p50 and p95 duration, and each upstream host's error counts and circuit-breaker
state (see MAPLE_USAGE_STATS and MAPLE_BREAKER below). After repeated
failures (timeouts, connection errors, 5xx answers, Cloudflare challenges) a
host is paused for a cooldown: its tools fail at once with an "unavailable"
error that says when to retry, instead of waiting for another timeout. The
docs://status resource lists the paused hosts.
Env var | Default | Purpose |
|
|
|
|
| HTTP bind address |
| unset, | Bearer token required on |
|
| Per-client rate limit |
|
| In-flight request cap; the excess waits 5 s, then gets 503 |
| unset | TLS in-process |
|
| Rate-limit on |
|
| Proxies that append to |
| project website, localhost | Browser origins allowed on |
|
| Response cache size per TTL bucket |
|
| Estimated memory cap for the response cache, all buckets together |
|
| Threads for parsing Excel and CSV files, and the time one parse may take |
|
| Longest a tool call may run |
|
| Pause requests to an upstream host after repeated failures; |
|
| Failures in a row, within the window, that pause a host, and how long before one probe request is sent |
|
|
|
| system temp, | Downloaded microdata cache; use a persistent volume when hosted |
| unset | Header the outermost proxy sets to the caller's own address (Cloudflare's |
| unset | Memory limit for DuckDB queries over downloaded files (patents, open databases, microdata), such as |
| system temp, | Where StatCan open-database (LODE) archives are unpacked, and the size cap (least recently used files go first); use a persistent volume when hosted |
|
| Largest open-database archive one call may download; |
| system temp, | CIPO patent table cache |
| system temp | Customs Tariff editions as Parquet (under 1 MB each, newest 12 kept) |
| system temp, | Ontario FIR years kept as Parquet (about 3 MB each); use a persistent volume when hosted |
| Downloads folder (home folder if there is none) | Where |
|
|
|
|
| Byte budget for one tool result (minimum 10,000); a larger result has its biggest lists trimmed, and |
|
| Counts calls and durations per tool name and UTC day, and upstream errors per host (never arguments or client addresses), in memory, and serves them at the public |
|
| How much of a Delta File one |
| system temp | Saved Delta File resume points (a few MB per day); |
License
MIT. Third-party notices are in THIRD_PARTY_NOTICES.md.
Security and conduct
Report a vulnerability privately through GitHub's
private vulnerability reporting;
see SECURITY.md. Changes are recorded in
CHANGELOG.md, and community expectations in
CODE_OF_CONDUCT.md.
Acknowledgments
MapleStats owes its architecture to EcuDataMCP, the MCP server for Ecuador's open data that I help maintain with DweskZ and its other contributors. Its approach to Canadian data owes much to the R developers who got there first: Jens von Bergmann (mountainMath) and his co-authors, including Dmitry Shkolnik (dshkol), Thierry Warin (statcanR), Valentin Lucet (rgovcan), and others. Thanks to them, and to everyone who publishes Canadian data in the open.
For other ways to get Canadian data, see the alternatives.
Available Tools
3 toolscall_toolCall a toolADestructiveInspect
Run one data tool found through search_tools or plan_query.
Use for: executing a tool by exact name with arguments that match the inputSchema 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 typed result, including a provenance block (source, URL, query time, freshness). 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 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).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact tool name as returned by search_tools or plan_query, e.g. 'boc_get_observations'. | |
| arguments | No | Object matching that tool's inputSchema from search_tools. Omit or pass {} for a tool with no required parameters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: data tools read public sources, reproduce_workbook can save an Excel file locally or return base64 on hosted exports, results include a provenance block, errors are typed MCP tool errors, and calls are subject to MAPLE_TOOL_TIMEOUT_SECONDS. It does not explicitly characterize destructive or write behavior in general, but the annotations already flag destructiveHint=true and the description is consistent with that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and use case, then covers error behavior and timeout constraints. It is somewhat long, but most details are operationally useful for a meta-tool that dispatches other tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex dispatcher with no output schema, the description is complete enough: it explains the return shape including provenance, how errors are surfaced, which tools cannot be called through it, and the timeout environment variable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description reinforces that 'name' must be exact and that arguments must match the target tool's inputSchema, but adds little beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Run one data tool found through search_tools or plan_query.' It clearly distinguishes call_tool from the discovery/planning siblings and explains the exact use case (executing a named tool with matching arguments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool ('executing a tool by exact name with arguments that match the inputSchema'), names where the name comes from (search_tools or plan_query), and states when not to use it ('search_tools, call_tool and plan_query cannot be called through it; call them directly').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plan_queryPlan queryARead-onlyIdempotentInspect
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.
| 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered; the description adds genuinely new behavior: it is offline, matches against this server's local source map, and calls no external API. It also previews the return surface (topics, ordered tools, local portals, caveats), which partly overlaps the output schema but usefully signals that it is a planning step, not a data fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then when-to-use, then return contents, then behavioral constraints, then bilingual keyword tail. Every section earns its place except the bilingual keyword list, which adds length that is only justified by search discoverability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter planning tool with full annotations and an output schema, nothing an agent needs is missing: purpose, sequencing relative to both siblings, follow-up action, offline behavior, and language effects are all covered, so the description does not need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 semantics: it fully specifies the lang parameter's effect ('gives the labels, purposes, caveats and guidance in French; tool and argument names stay as they are'), which is non-obvious behavior. The question parameter is not described abstractly but is effectively conveyed through the sample question, leaving only explicit format/length guidance absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Plan which sources answer a question that may span several agencies') and immediately distinguishes itself from siblings by naming both call_tool (execution) and search_tools (single-source lookup). An agent can pick this tool without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly prescribes when to use it ('the first call on a substantive question'), gives a concrete trigger example, defines the follow-up flow ('Then run the steps with call_tool'), and names the exclusion case with the alternative ('Use search_tools instead ... narrow, single-source need'). 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.
search_toolsSearch toolsARead-onlyIdempotentInspect
Find the right data tool for one specific need by plain-language search.
Use for: locating a tool when you know roughly what data you want (a StatCan table, Bank of Canada series, a city's open-data portal). Returns the best-matching tool definitions, ranked by relevance, each with its name, description and full input schema, in the same format as list_tools. Read-only; it searches this server's catalogue only and calls no external API. Use plan_query instead when a question may span several sources or you do not know where to start; use call_tool to run a tool once you have its name. Queries in English or French both work. An empty result means no tool matched: rephrase with topic words (e.g. 'housing starts' rather than 'CMHC table').
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What you need, in plain English or French, e.g. 'Calgary rent index' or 'taux de chômage Québec'. Topic words work better than tool names. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly/openWorld=false/idempotent), and the description adds genuinely new behavior: it searches only this server's catalogue, calls no external API, returns ranked best-matching tool definitions in list_tools format, and defines the empty-result case with recovery advice. These are traits the annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence, followed by use-for, boundaries, alternatives, and an edge-case recovery line. Every sentence carries distinct operational information with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter search tool with an output schema and full annotation coverage, nothing an agent needs is missing: trigger, scope, return shape, ranking behavior, language support, and failure recovery are all stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single query parameter is already well documented, so the baseline is 3. The description adds meaningful strategy beyond the schema: queries work in English or French, and topic words beat tool names, which shapes how an agent should phrase the argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (find/search) and resource (data tool) plus the scoping constraint that it searches this server's catalogue only. It explicitly names what it is not (plan_query, call_tool), so an agent can distinguish it from siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit 'Use for' trigger, then hands off with conditions: 'use plan_query instead when a question may span several sources or you do not know where to start' and 'use call_tool to run a tool once you have its name.' That is the full when/when-not/alternative set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.4.3- Changed
plan_query2 fields changed- added
Output schema / properties / provenance / properties / caveatsAdded value: +{ + "description": "Fitness-for-use cautions for this table or source, from MapleStats' rules (docs://planner/fitness-rules).", + "items": { + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / provenance / properties / commercial_useAdded 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." +}
1 tool update
v0.4.0- Changed
plan_query1 field changed- changed
Output schema / properties / provenance / properties / reproduce / defaultPrevious 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."
1 tool update
v0.2.0- Changed
plan_query2 fields changed- added
Output schema / properties / out_of_scopeAdded 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." +} - added
Output schema / properties / provenance / properties / licenceAdded 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)." +}
2 tool updates
v0.1.1- Changed
call_tool2 fields changed- changed
Input schema / properties / arguments / descriptionPrevious value: -"Arguments to pass to the tool"New value: +"Object matching that tool's inputSchema from search_tools. Omit or pass {} for a tool with no required parameters." - changed
Input schema / properties / name / descriptionPrevious value: -"The name of the tool to call"New value: +"Exact tool name as returned by search_tools or plan_query, e.g. 'boc_get_observations'."
- Changed
search_tools1 field changed- changed
Input schema / properties / query / descriptionPrevious value: -"Natural language query to search for tools"New value: +"What you need, in plain English or French, e.g. 'Calgary rent index' or 'taux de chômage Québec'. Topic words work better than tool names."
3 tool updates
v0.1.0- First observed
call_tool - First observed
plan_query - First observed
search_tools
TDQS
Scored across 3 tools
The three tools form a clean discovery/planning/execution triad, and each description explicitly states when to prefer the other (plan_query for multi-source questions, search_tools for a single narrow need, call_tool to execute). The only residual overlap is search_tools vs plan_query, both of which help an agent find the right tool, but the stated boundary (single source vs cross-source) resolves it in practice.
All three follow a snake_case verb_noun pattern (plan_query, call_tool, search_tools), which is predictable and readable. Minor deviation in that the noun objects are inconsistent in scope and number (query vs tool vs tools), but the pattern is clear enough that an agent can infer new tool names.
Three tools is on the lean side but justified here: the server is a gateway whose real surface (StatCan, BoC, open-data tools) is reached through search_tools and call_tool, so a thin meta-layer keeps the exposed surface small. A direct list_tools equivalent would round it out, but nothing feels padded or missing at this layer.
The surface covers the full workflow an agent needs: find a tool (search_tools), plan a multi-source investigation with ordering and caveats (plan_query), then execute with provenance and typed errors (call_tool). Gaps are minor — no batch/multi-tool execution, no direct catalogue listing or schema lookup without a search, and no result pagination — but each is workable via repeat calls.
Maintenance
Related MCP Connectors
Curated gateway to snapshot-versioned Canadian public data services with source provenance.
Access Statistics Canada data via the Web Data Services API
StatCan MCP — Statistics Canada (StatCan) via the Web Data Service (WDS). Free, no auth. Fills the…
Statistics Canada (StatCan) WDS MCP — Canadian official statistics (no auth)
Related MCP Servers
- AlicenseAqualityBmaintenanceEnables MCP-compatible clients to access Canadian statistical data from Statistics Canada via WDS and SDMX APIs, including search, download, and analysis capabilities.25167 PyPI7MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to search, explore, and analyze Québec open data (Données Québec, Ville de Montréal, IGO) via natural language, including SQL queries, geocoding, and spatial operations.1MIT
- AlicenseNot gradedqualityFmaintenanceProvides access to Statistics Canada official statistics without authentication, enabling AI agents to query Canadian economic and demographic data.2 npmMIT
- AlicenseAqualityDmaintenanceProvides LLM agents with live access to Canadian economic and financial data (exchange rates, interest rates, inflation, etc.) through the Bank of Canada Valet API, with no API key required.105MIT