Canadian open data: StatCan, Census, PUMFs, Bank of Canada, CMHC and open-data portals (EN/FR).
Scored across 3 tools
The three tools map cleanly onto distinct phases: plan_query for multi-source planning, search_tools for single-need discovery, and call_tool for execution. Each description explicitly states when to use the others instead, leaving no overlap or misselection risk.
All three names follow a uniform snake_case verb_noun pattern (call_tool, plan_query, search_tools) with no stylistic deviation. The convention is predictable and readable.
As a router/gateway fronting many underlying data tools (StatCan, Bank of Canada, open-data portals), three tools is exactly the right minimal surface for the plan-search-execute workflow. Each tool earns its place with no redundancy.
The plan → search → call cycle covers discovery and execution, and call_tool handles output including workbook reproduction and provenance. A dedicated browse/list tool is only implicitly covered by search_tools' list_tools-style output, a minor gap an agent can work around.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description goes further by explaining that invoked data tools read public sources, that reproduce_workbook may save an Excel file or return base64, that results include a provenance block, that failures surface as MCP tool errors with specific cases, and that calls are subject to a configurable timeout. This is unusually rich behavioral disclosure beyond annotations.
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 action, then covers use cases, return behavior, error behavior, exclusions, and timeout. Despite being longer than a single sentence, every section is informative for a dispatcher tool and there is no obvious filler.
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?
There is no output schema, so the description appropriately explains that the tool returns the invoked tool's typed result with a provenance block. It also covers the major error modes and timeout behavior. Given the complexity of a tool-calling dispatcher, the definition is complete enough for an agent to invoke it correctly.
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 both parameters are already documented in the input schema. The description reinforces the need for an exact tool name and arguments matching the referenced inputSchema, but this largely duplicates what the schema already states. No additional syntax, defaults, or constraints are added beyond the schema.
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 states a specific verb and resource: run one data tool by exact name. It distinguishes this tool from siblings by saying that search_tools, call_tool, and plan_query cannot be called through it and must be called directly. An agent can tell what this tool does without opening the 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?
It explicitly says to use this tool for executing a tool found through search_tools or plan_query. It also names the excluded meta-tools and instructs the agent to call them directly, and it explains that unknown names should trigger a search again. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
| 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. |
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.
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.
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.
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.
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.
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.
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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
call_toolplan_querysearch_toolsCurated gateway to snapshot-versioned Canadian public data services with source provenance.
Statistics Canada (StatCan) WDS MCP — Canadian official statistics (no auth)
StatCan MCP — Statistics Canada (StatCan) via the Web Data Service (WDS).
City of Peterborough GIS — Peterborough, Ontario (Canada) open geospatial data (ArcGIS).
Add one secure layer between your agents and this server.