MapleStats MCP

Search Canadian data tools

search_tools

Read-onlyIdempotent

Search Canadian official data: Statistics Canada, Bank of Canada, CMHC, provincial statistics agencies, federal departments and city portals.

Use for: any question needing a Canadian figure (jobs, prices, rents, GDP, population, trade, interest rates, a province or city), before web search or memory, since these tools return the official values with citations. Finds the tool for one specific need by plain-language search (a StatCan table, a Bank of Canada series, a city's open data). Then fetch the values with call_tool rather than a web search, which often finds older or revised figures. Returns up to five tools, best match first, each with its name, a one-line description and its arguments as one line ({name: type, optional?: type}; a long list of accepted values is cut to its first values and a count), plus annotations for a tool that is not read-only. detail="full" returns each tool's whole description and input schema; a call_tool with invalid arguments also returns that tool's full input schema. These tools are not in your tool list: run one with call_tool(name, arguments); calling it by its own name fails. 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').

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

Input Schema

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.
`detail`	No	'brief' (the default): each tool's name, one-line description and argument signature. 'full': the whole description and input schema.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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): each tool's name, one-line description and argument signature. 'full': the whole description and input schema."
+}

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 readOnly/idempotent/closed-world, but the description adds substantial behavior the annotations cannot express: max five results ordered best-match-first, the per-result payload (name, one-line description, argument signature, annotations only for non-read-only tools), truncation of long enum lists to first values plus a count, the detail="full" escalation, and the fallback where invalid call_tool arguments return that tool's full 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?

Purpose and audience are front-loaded and nearly every sentence carries unique operational information, including the critical warning that the found tools are not in the agent's tool list. It loses a point for being a dense single block with parenthetical asides and hard line breaks mid-sentence, making the return-format and invocation rules harder to scan than they need to be.

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?

For a two-parameter search router with tricky indirect-invocation semantics, everything an agent needs is present: what it searches, when to prefer siblings, result shape and ordering, how to escalate detail, how to handle empty results, and how to actually run a discovered tool. An output schema exists, so the return-shape prose is bonus rather than a gap-filler.

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 and the description largely restates what the schema already says about query phrasing and brief/full. It earns above baseline by explaining the operational consequence of detail="full" (whole description plus input schema, also returned on invalid call_tool arguments) and by noting English or French queries both work, which the schema does not state.

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 and resource ("Search Canadian official data") and enumerates the concrete source families it covers (Statistics Canada, Bank of Canada, CMHC, provincial agencies, federal departments, city portals). It also disambiguates from both siblings by naming them: plan_query for multi-source questions, call_tool to execute a found 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?

Explicit when-to-use ("any question needing a Canadian figure... before web search or memory"), explicit alternatives with conditions ("Use plan_query instead when a question may span several sources or you do not know where to start"), and explicit failure recovery ("An empty result means no tool matched: rephrase with topic words"). It even gives a concrete bad-vs-good query example.

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.