de en es ja ko ru zh

mcp-canada

Name: mcp-canada
Author: ReyemTech

by ReyemTech

Overview Schema Related Servers Score Discussions

Python

Remote

295 Tools, ~107 Prompts und ~141 Ressourcen über 9 Bundes-APIs + 9 Provinz-APIs + 2 Kommunal-APIs + 1 lokalen SQLite-Datenspeicher — Wechselkurse, Parlamentsdaten, Produktrückrufe, Arzneimittelinformationen, 80.000+ offene Datensätze, Lebensmittelnährwertdaten, Echtzeitwetter, Einwanderungsstatistiken, Daten der Provinz Ontario, Daten der Stadt Toronto, ArcGIS-Hub-Daten der Region York, CKAN- + WFS-Geodaten von British Columbia, CKAN- + ArcGIS-IQA-Daten von Quebec (Données Québec), offene Daten von Alberta + AER-Energie + WMBappServices-Waldbrände + AHSGIS-Gesundheit + 511-Alberta-Transport, Manitoba-Geoportal (ArcGIS Hub) + 511-Manitoba-Transport, Saskatchewan-Geoportal (ArcGIS Hub) + WSA-Wasserinfrastruktur + SPSA-Feuerverbote, Socrata-SODA-Portal von Nova Scotia (data.novascotia.ca), Bundes-CKAN-Erkennung von New Brunswick + GeoNB-Geodaten über nackten ArcGIS-Server + gnb.socrata.com-Socrata-Portal + schlüsselgeschützter 511-NB-Transport und persistenter lokaler Speicher. Alles zweisprachig (Englisch/Französisch).

Erstes ArcGIS-Hub-Modul — die gemeinsame Infrastruktur in shared/arcgis_hub.py ist für zukünftige kanadische Kommunalmodule wiederverwendbar (BC, Calgary, Edmonton und andere Städte, die über ArcGIS Hub veröffentlichen). Erstes OGC-WFS-Modul — BC führt WFS-2.0-(OGC)-Unterstützung über shared/ogc.py ein und macht WFS zur dritten Portaltechnologie neben CKAN und ArcGIS Hub. Siehe docs://bc/wfs-query-guide für den zweistufigen CKAN→WFS-Workflow.

Schnellstart

# Auto-configure your platform (interactive)
uvx mcp-canada install

# Or name platforms directly
uvx mcp-canada install claude-desktop cursor vscode

Unterstützt 14 Plattformen: Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Zed, Codex CLI, Gemini CLI, Amazon Q, OpenCode, Cline, Roo Code, Goose CLI, Junie CLI.

Manuelle Einrichtung

Fügen Sie zu ~/Library/Application Support/Claude/claude_desktop_config.json hinzu:

{
  "mcpServers": {
    "mcp-canada": {
      "command": "uvx",
      "args": ["mcp-canada"]
    }
  }
}

claude mcp add mcp-canada -- uvx mcp-canada

git clone https://github.com/reyemtech/mcp-canada.git
cd mcp-canada
uv run mcp-canada

Optionen

Flag	Beschreibung	Beispiel
`--transport`	Transportprotokoll	`--transport sse`
`--port`	Port für SSE/HTTP	`--port 8000`
`--modules`	Nur bestimmte Module laden	`--modules bank_of_canada,recalls`
`--verbose`	INFO-Level-Logging	`--verbose`
`--debug`	DEBUG-Level-Logging	`--debug`

Umgebungsvariable: MCP_CANADA_MODULES=bank_of_canada,recalls

Related MCP server: canlii-mcp

Beispiele

Siehe die Dokumentationsseite für API-übergreifende Intelligence-Szenarien — von der Verfolgung der Präriedürre bis zum kanadischen Dollar, über den Aufbau pharmazeutischer Sicherheitsaudits, bis zur Erstellung von Rechenschaftsberichten für Abgeordnete, bis zur Verknüpfung von Daten aus mehreren APIs in einer einzigen SQL-Abfrage. Jedes Beispiel enthält den exakten Prompt und die Tool-Kette, die Sie heute ausführen können. Der Quellcode bleibt in EXAMPLES.md.

So funktioniert die Suche

Bei 250 Tools würde die Auflistung aller die Hälfte des Kontextfensters eines Agenten verbrauchen. Stattdessen ermöglicht die BM25-Suche Agenten, genau das zu finden, was sie brauchen:

Agent: "What tools do you have for exchange rates?"

→ discover_tools("exchange rate CAD")
→ Returns: boc_get_exchange_rates, boc_get_observations

→ call_tool("boc_get_exchange_rates", {"currency": "USD", "recent": 3})
→ Returns: {"_meta": {...}, "data": [{"date": "2026-04-02", "value": 1.3918, ...}]}

Agenten sehen 5 immer sichtbare Tools:

Tool	Zweck
`discover_tools`	BM25-Suche in natürlicher Sprache über alle Tools
`call_tool`	Führt jedes gefundene Tool per Name aus
`list_modules`	Listet verfügbare API-Module mit Tool-Anzahl auf
`plan_query`	Plant eine mehrstufige Abfrage über kanadische Regierungsdaten-APIs
`execute_batch`	Führt mehrere Tool-Aufrufe parallel mit Fehlerisolierung pro Schritt aus

Module

Alle Tools akzeptieren lang: "en" | "fr" für zweisprachige Unterstützung. Antworten enthalten eine _meta-Hülle mit Quellenangabe und Cache-Status. Durchsuchen Sie die vollständige, durchsuchbare Tool-Referenz für aktuelle Tool-Parameter und Quell-APIs.

Modul	Ebene	Tools	Prompts	Ressourcen	Beschreibung
Meta / Discovery	—	5	—	—	Immer sichtbare Orchestrierungswerkzeuge (`discover_tools`, `call_tool`, `list_modules`, `plan_query`, `execute_batch`)
Bank of Canada	Bund	8	5	7	Wechselkurse, Zinssätze, Rohstoffpreise, Inflation — Valet API
CKAN Open Data	Bund	7	5	7	80.000+ Bundesdatensätze — open.canada.ca
Drug Database	Bund	8	5	7	Arzneimittelprodukte, Inhaltsstoffe, Einstufungen — Health Canada DPD
IRCC Immigration	Bund	10	5	7	PR, Studien-/Arbeitsgenehmigungen, Express Entry, Asyl — IRCC Open Data
Nutrient File	Bund	8	5	7	Nährwertdaten von Lebensmitteln — Canadian Nutrient File
Open Parliament	Bund	10	5	7	Gesetzesentwürfe, Abgeordnete, Abstimmungen, Wahlzettel, Hansard-Debatten — Open Parliament API
Recalls & Safety	Bund	6	4	6	Rückrufe von Lebensmitteln, Fahrzeugen und Gesundheitsprodukten — Healthy Canadians
Statistics Canada	Bund	15	6	8	Zeitreihen, Cube-Metadaten, SDMX-Filterung — StatCan WDS
Weather	Bund	34	6	8	Wetterbedingungen, Klima, Luftqualität, Hydrologie, Meer, Radar — MSC GeoMet
Alberta	Provinz	24	6	7	CKAN + AER-Energie + WMBappServices-Waldbrände + AHSGIS-Gesundheit + 511 Alberta — open.alberta.ca
British Columbia	Provinz	20	6	7	CKAN + WFS-Geodaten — BC Data Catalogue
Manitoba	Provinz	20	6	7	ArcGIS Hub + 511 Manitoba — geoportal.gov.mb.ca
Saskatchewan	Provinz	13	6	7	ArcGIS Hub + WSA-Wasser + SPSA-Feuerverbote — geohub.saskatchewan.ca
New Brunswick (`new_brunswick/`)	Provinz	22	6	7	Bundes-CKAN + GeoNB nackter ArcGIS-Server + gnb.socrata.com Socrata + schlüsselgeschützter 511-NB-Transport — geonb.snb.ca
Nova Scotia	Provinz	16	6	7	Socrata-SODA-Portal (Aquakultur, Umwelt, Gesundheit) — data.novascotia.ca
Ontario	Provinz	6	4	6	3.000+ Provinzdatenbestände — Ontario Open Data
Quebec	Provinz	18	6	7	Föderiertes CKAN (139 Organisationen) — Données Québec
Toronto	Kommunal	12	6	8	TTC, Stadtteile, 311, RentSafe — Toronto Open Data
York Region	Kommunal	27	5	8	4 ArcGIS-Hub-Portale (York Region, Markham, Newmarket, Aurora)
Local Datastore	Lokal	6	4	6	SQLite-Persistenz für API-übergreifende SQL-JOINs — `~/.mcp-canada/datastore.db`
Gesamt		295	~107	~141

Antwortformat

Alle Tools geben eine konsistente Hülle zurück:

{
  "_meta": {
    "source": {"api": "bank-of-canada-valet", "url": "https://..."},
    "cached": true,
    "lang": "en",
    "timestamp": "2026-04-04T12:00:00Z"
  },
  "data": [ ... ]
}

Fehler geben zurück:

{
  "error": {
    "code": "INVALID_SERIES",
    "message": "Series 'FXXYZCAD' not found.",
    "suggestions": ["FXUSDCAD", "FXEURCAD"]
  }
}

Architektur

src/mcp_canada/
├── server.py              # FastMCP entry point, transport, module loading
├── shared/                # Cross-module utilities
│   ├── cache.py           # TTL-based in-memory cache (aiocache)
│   ├── envelope.py        # Response/error envelope (make_response/make_error)
│   ├── http.py            # Shared HTTP client with retry (tenacity)
│   ├── rate_limiter.py    # Per-source token bucket
│   └── i18n.py            # Bilingual error messages
├── meta/
│   └── list_modules.py    # list_modules meta-tool
└── modules/
    ├── bank_of_canada/    # 8 tools — Valet API
    ├── open_parliament/   # 10 tools — Parliament API
    ├── recalls/           # 6 tools — Healthy Canadians API
    ├── drug_database/     # 8 tools — Health Canada DPD
    ├── ckan/              # 7 tools — Open Data Portal
    ├── nutrient_file/     # 8 tools — Canadian Nutrient File
    ├── datastore/         # 6 tools — local SQLite persistence
    ├── ircc/              # 10 tools — IRCC Immigration Open Data
    ├── ontario/           # 6 tools — Ontario Open Data Catalogue
    ├── toronto/           # 12 tools — City of Toronto Open Data Portal
    ├── york_region/       # 27 tools — York Region ArcGIS Hub (4 portals)
    ├── british_columbia/  # 20 tools — BC Data Catalogue + WFS
    ├── manitoba/          # 20 tools — geoportal.gov.mb.ca ArcGIS Hub + 511 Manitoba
    ├── saskatchewan/      # 13 tools — geohub.saskatchewan.ca ArcGIS Hub + WSA water + SPSA fire bans
    ├── quebec/            # 18 tools — Données Québec CKAN
    ├── alberta/           # 24 tools — open.alberta.ca CKAN + AER + WMB + AHSGIS + 511
    ├── nova_scotia/       # 16 tools — data.novascotia.ca Socrata SODA
    ├── statcan/           # 15 tools — Statistics Canada WDS + SDMX
    └── weather/           # 34 tools — MSC GeoMet OGC API
        ├── current/       # 5 tools — realtime conditions, forecast, alerts
        ├── climate/       # 7 tools — daily/monthly/normals/trends
        ├── aqhi/          # 3 tools — air quality health index
        ├── hydro/         # 5 tools — water levels, flow, flood risk
        ├── marine/        # 3 tools — marine forecasts, hurricane tracks
        ├── severe/        # 3 tools — radar, lightning, UV index
        ├── snow/          # 2 tools — snow depth, snow water equivalent
        ├── collections/   # 2 tools — collection browser and direct query
        └── summary/       # 4 tools — composite summary, extremes, growing season, degree days

Jedes Modul folgt einem 7-Datei-Muster:

Datei	Zweck
`__init__.py`	Modulname und Beschreibung
`constants.py`	Basis-URL, Ratenbegrenzungen, Cache-TTLs, API-Zuordnungen
`schemas.py`	Pydantic-v2-Antwortmodelle (immer flach)
`client.py`	Asynchrone HTTP-Funktionen mit Caching und Ratenbegrenzung
`tools.py`	`@tool`-dekorierte MCP-Toolfunktionen
`prompts.py`	`@prompt`-Funktionen — geführte Workflows + Schnellnachschläge
`resources.py`	`@resource`-Funktionen — Kataloge, Dokumente, Vorlagen

Neue Module werden automatisch erkannt – legen Sie einen Ordner in modules/ ab, und das Modul wird über FileSystemProvider registriert.

Entwicklung

# Install dependencies
uv sync

# Run tests (~2000 unit tests, ~15s)
uv run pytest

# Run integration tests against live APIs (~2min)
uv run pytest tests/integration/ -v -m integration --timeout=120

# Type check and lint
uv run pyright
uv run ruff check src/ tests/

# Coverage (must be ≥95%)
uv run pytest --cov=src/mcp_canada --cov-fail-under=95

Mitwirken

Jedes Modul ist in sich geschlossen. Um eine neue API hinzuzufügen:

Erstellen Sie src/mcp_canada/modules/your_api/ mit dem 7-Dateien-Muster
Fügen Sie am selben Ort __tests__/ mit Unit-Tests hinzu
Fügen Sie Integrationstests in tests/integration/test_tool_scenarios.py hinzu
Fügen Sie eine Moduldokumentation in docs/modules/ hinzu und aktualisieren Sie die Modultabelle in dieser README

Siehe CLAUDE.md für Codierungskonventionen.

Änderungsprotokoll

Siehe CHANGELOG.md für Änderungen von Version zu Version, oder stöbern Sie in den GitHub Releases.

Sicherheit

Eine Schwachstelle gefunden? Bitte kein öffentliches Issue eröffnen. Senden Sie eine E-Mail an contact@reyem.tech mit Details und Reproduktionsschritten. Wir unterstützen die neueste Nebenversion auf PyPI.

Community

Fragen & Ideen: GitHub Discussions
Fehler & Funktionsanfragen: GitHub Issues
Kontakt: contact@reyem.tech

Lizenz

MIT — Reyem Tech

Datenquellen

Daten aus den folgenden Regierungsquellen werden von dieser Bibliothek unter ihren jeweiligen Lizenzen abgerufen:

Nova Scotia Open Data — Lizenziert unter der Open Government Licence – Nova Scotia v1.1. Enthält Informationen des öffentlichen Sektors, die von der Provinz Nova Scotia bereitgestellt werden.

Sternenverlauf

Available Tools

5 tools

call_toolB

Call a tool by name with the given arguments.

Use this to execute tools discovered via search_tools.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	The name of the tool to call
`arguments`	No	Arguments to pass to the tool

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as return value, side effects, rate limits, or error handling. For a tool that invokes other tools, this lack of transparency is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two sentences with no redundant or irrelevant information. It is tightly written and front-loads the core purpose.

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

Completeness2/5

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

Despite the simple schema, the tool is a meta-tool that executes others. The description fails to explain the return value (the called tool's output) or address error conditions, prerequisites, or synchronization behavior. This leaves the agent without crucial context.

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?

The input schema has 100% description coverage on both parameters ('name' and 'arguments'), so the schema already defines their purpose. The description adds no extra meaning beyond 'with the given arguments,' resulting in a baseline score of 3.

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 description clearly states the action ('call') and the resource ('tool'), and distinguishes from sibling tools like discover_tools and execute_batch by specifying it executes tools discovered via search_tools. The purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises to use this tool after discovering tools via search_tools, providing some context. However, it does not explicitly state when not to use it (e.g., for batch operations) or mention alternative tools like execute_batch. The guidance is minimal.

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

discover_toolsA

Search for tools using natural language.

Returns matching tool definitions ranked by relevance, in the same format as list_tools.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Natural language query to search for tools

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description must disclose behaviors. It states the tool is a read-only search returning ranked definitions in a specific format, which is adequate. However, it omits any mention of side effects, rate limits, or scope (e.g., whether it searches across all modules). The behavior is minimally described but not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no extra words. It front-loads the action and efficiently communicates purpose and return format. Every sentence adds value.

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?

Given the tool's simplicity (1 param, no annotations, output schema exists), the description covers the core purpose and output. It could mention that results are from all available tools or that it is a read operation, but it is largely complete for a search tool.

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?

The input schema covers 100% of parameters (only 'query' with a description). The description rephrases the schema ('Natural language query') without adding new meaning, such as query format, length limits, or examples. Baseline score of 3 is appropriate since schema does the heavy lifting.

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 description clearly states the tool searches for tools using natural language, with a specific verb ('Search') and resource ('tools'). It explains the return format (matching definitions ranked by relevance, like list_tools), which differentiates it from siblings like list_modules and plan_query.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for finding tools by description, but provides no explicit guidance on when to use it versus alternatives like list_tools or call_tool. There are no 'when not to use' or exclusion criteria, leaving the agent to infer context.

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

execute_batchA

Execute multiple tool calls in parallel and return aggregated results.

Accepts either a plan_query output (dict with 'steps' key) or a raw list of tool call objects. Runs all valid steps in parallel using asyncio.gather with per-step error isolation — one failed step does not cancel others.

Use for: running multiple tool calls at once, executing a plan from plan_query, batch queries across multiple APIs, parallel data fetching, multi-source aggregation.

Keywords: batch, execute, parallel, multiple tools, run plan, aggregate, multi-step, concurrent, simultaneous, gather, dispatch, bulk, workflow

ParametersJSON Schema

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

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

Discloses key behaviors: uses asyncio.gather for parallel execution, per-step error isolation (one failure doesn't cancel others), and accepts specific input formats. With no annotations, this adequately reveals the execution model.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Efficiently structured: purpose first, then behavior, followed by use cases and keywords. Every sentence adds value without redundancy.

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?

Covers input format, execution model, error isolation, and use cases. With an output schema present, the return values are implicitly documented. Could add timeout details but overall comprehensive for the tool's complexity.

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?

Despite 0% schema coverage, description adds meaning by explaining the `calls` parameter accepts either a plan_query output or raw list of tool call objects. The `lang` parameter is an enum with default, and its description is not needed beyond schema.

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 description clearly states 'Execute multiple tool calls in parallel and return aggregated results,' effectively distinguishing it from siblings like call_tool (single call) and plan_query (generates plans without execution).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit use cases like 'running multiple tool calls at once, executing a plan from plan_query,' offering clear guidance on when to use. Could improve by mentioning when not to use, but positive guidance is strong.

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

list_modulesA

List all registered API modules with tool counts and descriptions.

Use this to understand what data sources are available before calling discover_tools for specific queries. Keywords: modules, APIs, data sources, available tools, capabilities.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, but the description discloses the read-only nature implicitly. It does not mention auth requirements, rate limits, or return format, though the tool is simple and likely safe.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, no fluff. The purpose is front-loaded, and keywords at the end aid searchability.

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?

Given the output schema exists, the description need not detail return values. It provides enough context to understand the tool's role, though it could mention the structure of the module list.

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?

There are no parameters, and schema coverage is 100% trivially. The description adds value by stating what the output contains (modules with tool counts and descriptions), which goes beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List all registered API modules with tool counts and descriptions' and positions it as a precursor to discover_tools, distinguishing its purpose from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly guides the agent to 'Use this to understand what data sources are available before calling discover_tools for specific queries', providing clear context but no when-not or alternatives.

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

plan_queryA

Plan a multi-step query across Canadian government data APIs.

Returns a structured execution plan with the most relevant tool names for the given natural language question. Use execute_batch to run the plan.

Use for: orchestrating queries that span multiple data sources, finding which tools to use for a complex question, multi-API planning, cross-module queries, batch query preparation.

Keywords: plan, query, multi-step, orchestrate, batch, cross-module, execution plan, tool selection, NL query, natural language, discover, which tools, what tools, how to query, planning, workflow

ParametersJSON Schema

Name	Required	Default
`lang`	No	en
`query`	Yes
`top_k`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It transparently states the tool is for planning only and directs to 'execute_batch' for execution. It doesn't cover limitations or error behavior, but the planning nature is well communicated.

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 description is front-loaded with core purpose but includes a lengthy keyword list that adds redundancy. It is mostly concise but could be tightened for efficiency.

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

Completeness3/5

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

The description covers the tool's role and relationship to 'execute_batch', but lacks examples, parameter guidance, and constraints. With an output schema present, some gaps are acceptable, but parameter semantics are missing.

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

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description adds no meaning for parameters 'query', 'top_k', or 'lang'. It fails to describe input semantics beyond schema defaults and enums, requiring the agent to infer.

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 description clearly states the tool plans multi-step queries across Canadian government data APIs and returns a structured execution plan. It uses specific verbs like 'plan' and 'orchestrate', and is easily distinguishable from siblings like 'call_tool' and 'execute_batch'.

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?

The description explicitly lists use cases (e.g., multi-API planning, cross-module queries) and advises using 'execute_batch' for execution. This provides clear when-to-use guidance and references an alternative sibling.

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. Dates show when Glama detected each change.

5 tool updatesv0.7.0May 29, 2026
- First observedcall_tool
- First observeddiscover_tools
- First observedexecute_batch
- First observedlist_modules
- First observedplan_query

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation4/5

Tools have distinct purposes: call_tool vs execute_batch differ in batching; discover_tools vs plan_query both find tools but plan_query adds orchestration. Minor overlap but descriptions clarify.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (call_tool, discover_tools, execute_batch, list_modules, plan_query). No deviations.

Tool Count4/5

5 tools is appropriate for a meta-server that provides discovery and execution. Not too few or too many for the gateway purpose, but could include a direct browse tool.

Completeness4/5

Covers the discovery-to-execution pipeline well: list modules, discover tools, plan queries, execute. Missing a tool for inspecting tool details directly, but discover_tools suffices.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
openfolio
io.github.dodenbach
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
Government Data Open Data Search
1
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
nyc-property-intel
io.github.ccedacero
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
Real Estate Government Data
27

Related MCP Servers

Toronto MCP Server
Open Data Government Data Search
Toronto-inc
F
license
Not graded
quality
D
maintenance
An MCP server that provides tools for intelligently querying, analyzing, and retrieving datasets from Toronto's CKAN-powered open data portal. It enables AI assistants to perform natural language searches, inspect data structures, and track dataset update frequencies across the city's open data catalog.
Updated a year ago (2025-08-10 15:32 UTC)
12
-
canlii-mcp
Legal & Compliance Government Data
Vaquill-AI
A
license
A
quality
C
maintenance
An MCP server providing AI assistants access to Canadian case law and legislation metadata from CanLII across all jurisdictions, supporting search and citation relationships.
Updated 2 months ago (2026-07-09 04:40 UTC)
7
20
5
MIT
mcp-brasil
Government Data Open Data
bob-reis
A
license
Not graded
quality
D
maintenance
MCP Server for accessing 36 Brazilian public data sources and 1 agent, enabling AI agents to query government data on economy, legislation, transparency, judiciary, elections, environment, health, and more.
Updated 3 months ago (2026-06-12 02:53 UTC)
MIT
WorkspaceAlberta
Government Data Open Data Search
HarleyCoops
F
license
Not graded
quality
B
maintenance
MCP server for Canadian procurement intelligence, enabling unified search of federal and Alberta tender opportunities, deadline tracking, profile-based matching, daily briefs, and AI-assisted bid analysis.
Updated 4 days ago (2026-09-03 06:39 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ReyemTech/mcp-canada'

If you have feedback or need assistance with the MCP directory API, please join our Discord server