Skip to main content
Glama
Sign In
MapleStats MCP

MapleStats MCP

by dsanchezp18
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Run a Canadian data tool

call_tool
Read-onlyIdempotent

Run a Canadian open-data tool chosen via search_tools or plan_query, passing its exact name and schema-matched arguments to get typed results with provenance.

Instructions

Run one Canadian data tool (Statistics Canada, Bank of Canada, CMHC, provincial and city sources) 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).

Input Schema

NameRequiredDescriptionDefault
nameYesExact tool name as returned by search_tools or plan_query, e.g. 'boc_get_observations'.
argumentsNoObject matching that tool's inputSchema from search_tools. Omit or pass {} for a tool with no required parameters.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.1
    • changedInput schema / properties / arguments / description
      Previous 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."
    • changedInput schema / properties / name / description
      Previous 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'."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the annotations, it discloses the return shape (the routed tool's typed result plus a provenance block with source, URL, query time and freshness), the error taxonomy (unknown tool, field-level validation errors, typed upstream/empty-match errors), and the MAPLE_TOOL_TIMEOUT_SECONDS default of 120. The one unreconciled point is the note that reproduce_workbook can write an Excel file to disk while the annotations declare readOnlyHint=true and destructiveHint=false; the write is disclosed, but the description never says whether the wrapper's read-only annotation still applies when delegating to such a tool.

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?

The definition is front-loaded with the purpose and an explicit 'Use for:' clause, then moves to returns, errors, and constraints — a sensible order. It is longer than average and the error paragraph could be tightened (three error classes described at similar length), but nearly every sentence carries operational information.

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?

Although there is no output schema, the description explains what comes back (typed result plus provenance) and enumerates failure modes, so an agent can both call it and interpret responses. For a two-parameter dispatcher, nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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, including the 'exact tool name' constraint and the 'omit or pass {}' case. The description restates that arguments must match the inputSchema returned by search_tools but adds no format, size, or nesting guidance beyond the schema, so the baseline of 3 applies.

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?

The first sentence gives a specific verb and resource with scope: 'Run one Canadian data tool (Statistics Canada, Bank of Canada, CMHC, provincial and city sources) found through search_tools or plan_query.' That distinguishes it unambiguously from the two siblings, which are lookup/planning tools rather than execution.

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?

It states the prerequisite flow (discover with search_tools or plan_query, then call by exact name), the exclusion (search_tools, call_tool and plan_query cannot be invoked through it — call them directly), and the fallback when a name is wrong ('search again for the exact name'). Rarely is routing guidance this explicit.

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

Deploy Server

Other Tools