295개 도구, ~107개 프롬프트, ~141개 리소스 — 9개 연방 API + 9개 주 API + 2개 시 API + 1개 로컬 SQLite 데이터 저장소에 걸쳐 제공 — 환율, 의회 데이터, 제품 리콜, 의약품 정보, 80,000개 이상의 공개 데이터셋, 식품 영양 데이터, 실시간 날씨, 이민 통계, 온타리오 주 데이터, 토론토 시 데이터, York Region ArcGIS Hub 데이터, 브리티시컬럼비아 CKAN + WFS 지리공간 데이터, 퀘벡 Données Québec CKAN + ArcGIS IQA 데이터, 앨버타 공개 데이터 + AER 에너지 + WMBappServices 산불 + AHSGIS 보건 + 511 Alberta 교통, 매니토바 지오포털(ArcGIS Hub) + 511 Manitoba 교통, 서스캐처원 지오포털(ArcGIS Hub) + WSA 수자원 인프라 + SPSA 산불 금지, Nova Scotia Socrata SODA 포털(data.novascotia.ca), New Brunswick 연방 CKAN 검색 + GeoNB 순수 ArcGIS Server 지리공간 데이터 + gnb.socrata.com Socrata 포털 + 키 게이트 511 NB 교통, 그리고 영구 로컬 저장소. 모두 이중 언어(영어/프랑스어) 지원.
최초의 ArcGIS Hub 모듈 —
shared/arcgis_hub.py의 공유 인프라는 향후 캐나다 시 모듈(BC, Calgary, Edmonton 및 ArcGIS Hub를 통해 데이터를 게시하는 기타 도시)에 재사용할 수 있습니다. 최초의 OGC WFS 모듈 — BC는shared/ogc.py를 통해 WFS 2.0(OGC) 지원을 도입하여 WFS를 CKAN 및 ArcGIS Hub에 이어 세 번째 포털 기술로 만듭니다. CKAN→WFS 2단계 워크플로는docs://bc/wfs-query-guide를 참조하세요.
# Auto-configure your platform (interactive)
uvx mcp-canada install
# Or name platforms directly
uvx mcp-canada install claude-desktop cursor vscode14개 플랫폼 지원: Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Zed, Codex CLI, Gemini CLI, Amazon Q, OpenCode, Cline, Roo Code, Goose CLI, Junie CLI.
~/Library/Application Support/Claude/claude_desktop_config.json에 추가:
{
"mcpServers": {
"mcp-canada": {
"command": "uvx",
"args": ["mcp-canada"]
}
}
}claude mcp add mcp-canada -- uvx mcp-canadagit clone https://github.com/reyemtech/mcp-canada.git
cd mcp-canada
uv run mcp-canada플래그 | 설명 | 예시 |
| 전송 프로토콜 |
|
| SSE/HTTP 포트 |
|
| 특정 모듈만 로드 |
|
| INFO 수준 로깅 |
|
| DEBUG 수준 로깅 |
|
환경 변수: MCP_CANADA_MODULES=bank_of_canada,recalls
Related MCP server: canlii-mcp
API 간 인텔리전스 시나리오는 문서 사이트 를 참조하세요 — 대평원 가뭄을 캐나다 달러까지 추적하기, 제약 안전 감사 구축하기, 하원의원 책임 브리핑 작성하기, 단일 SQL 쿼리에서 여러 API의 데이터 조인하기 등. 각 예시에는 오늘 바로 실행할 수 있는 정확한 프롬프트와 도구 체인이 포함되어 있습니다. 원본은 EXAMPLES.md에 남아 있습니다.
250개의 도구가 있으므로 모두 나열하면 에이전트의 컨텍스트 창 절반을 소비하게 됩니다. 대신 BM25 검색을 통해 에이전트가 정확히 필요한 것을 찾을 수 있습니다:
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, ...}]}에이전트는 항상 표시되는 5개 도구를 볼 수 있습니다:
도구 | 용도 |
| 모든 도구에 대한 BM25 자연어 검색 |
| 이름으로 검색된 도구 실행 |
| 도구 수와 함께 사용 가능한 API 모듈 나열 |
| 캐나다 정부 데이터 API에 대한 다단계 쿼리 계획 |
| 단계별 오류 격리로 여러 도구 호출을 병렬 실행 |
모든 도구는 이중 언어 지원을 위해 lang: "en" | "fr"을 허용합니다. 응답에는 출처 속성과 캐시 상태가 포함된 _meta 봉투가 포함됩니다. 현재 도구 매개변수와 소스 API는 완전하고 검색 가능한 도구 참조 를 참조하세요.
모듈 | 수준 | 도구 | 프롬프트 | 리소스 | 설명 |
— | 5 | — | — | 항상 표시되는 오케스트레이션 도구( | |
연방 | 8 | 5 | 7 | 환율, 금리, 상품 가격, 인플레이션 — Valet API | |
연방 | 7 | 5 | 7 | 80,000개 이상의 연방 데이터셋 — open.canada.ca | |
연방 | 8 | 5 | 7 | 의약품, 성분, 분류 — Health Canada DPD | |
연방 | 10 | 5 | 7 | 영주권, 학업/취업 허가, Express Entry, 망명 — IRCC Open Data | |
연방 | 8 | 5 | 7 | 식품 영양 데이터 — Canadian Nutrient File | |
연방 | 10 | 5 | 7 | 법안, 하원의원, 투표, 무기명 투표, Hansard 토론 — Open Parliament API | |
연방 | 6 | 4 | 6 | 식품, 차량, 건강 제품 리콜 — Healthy Canadians | |
연방 | 15 | 6 | 8 | 시계열, 큐브 메타데이터, SDMX 필터링 — StatCan WDS | |
연방 | 34 | 6 | 8 | 기상, 기후, 대기질, 수문, 해양, 레이더 — MSC GeoMet | |
주 | 24 | 6 | 7 | CKAN + AER 에너지 + WMBappServices 산불 + AHSGIS 보건 + 511 Alberta — open.alberta.ca | |
주 | 20 | 6 | 7 | CKAN + WFS 지리공간 — BC Data Catalogue | |
주 | 20 | 6 | 7 | ArcGIS Hub + 511 Manitoba — geoportal.gov.mb.ca | |
주 | 13 | 6 | 7 | ArcGIS Hub + WSA 수자원 + SPSA 산불 금지 — geohub.saskatchewan.ca | |
New Brunswick ( | 주 | 22 | 6 | 7 | 연방 CKAN + GeoNB 순수 ArcGIS Server + gnb.socrata.com Socrata + 키 게이트 511 NB 교통 — geonb.snb.ca |
주 | 16 | 6 | 7 | Socrata SODA 포털(양식업, 환경, 보건) — data.novascotia.ca | |
주 | 6 | 4 | 6 | 3,000개 이상의 주 데이터셋 — Ontario Open Data | |
주 | 18 | 6 | 7 | 연합 CKAN(139개 기관) — Données Québec | |
시 | 12 | 6 | 8 | TTC, 지역구, 311, RentSafe — Toronto Open Data | |
시 | 27 | 5 | 8 | 4개 ArcGIS Hub 포털(York Region, Markham, Newmarket, Aurora) | |
로컬 | 6 | 4 | 6 | API 간 SQL JOIN을 위한 SQLite 영속성 — | |
합계 | 295 | ~107 | ~141 |
모든 도구는 일관된 봉투를 반환합니다:
{
"_meta": {
"source": {"api": "bank-of-canada-valet", "url": "https://..."},
"cached": true,
"lang": "en",
"timestamp": "2026-04-04T12:00:00Z"
},
"data": [ ... ]
}오류는 다음과 같이 반환됩니다:
{
"error": {
"code": "INVALID_SERIES",
"message": "Series 'FXXYZCAD' not found.",
"suggestions": ["FXUSDCAD", "FXEURCAD"]
}
}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각 모듈은 7파일 패턴을 따릅니다:
파일 | 용도 |
| 모듈 이름 및 설명 |
| 기본 URL, 속도 제한, 캐시 TTL, API 매핑 |
| Pydantic v2 응답 모델(항상 평면 구조) |
| 캐싱 및 속도 제한이 있는 비동기 HTTP 함수 |
|
|
|
|
|
|
새 모듈은 자동으로 감지됩니다 — modules/에 폴더를 넣으면 FileSystemProvider를 통해 등록됩니다.
# 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각 모듈은 독립적입니다. 새 API를 추가하려면:
7개 파일 패턴으로 src/mcp_canada/modules/your_api/ 생성
단위 테스트가 포함된 동일 위치 __tests__/ 추가
tests/integration/test_tool_scenarios.py에 통합 테스트 추가
docs/modules/에 모듈 문서를 추가하고 이 README의 Modules 표를 업데이트
코딩 규칙은 CLAUDE.md를 참조하세요.
버전별 변경 사항은 CHANGELOG.md를 참조하거나 GitHub Releases를 확인하세요.
취약점을 발견하셨나요? 공개 이슈를 열지 마십시오. 세부 정보와 재현 단계를 contact@reyem.tech로 이메일로 보내주세요. PyPI에서 최신 마이너 버전을 지원합니다.
질문 및 아이디어: GitHub Discussions
버그 및 기능 요청: GitHub Issues
연락처: contact@reyem.tech
이 라이브러리는 다음 정부 소스의 데이터를 각각의 라이선스 조건에 따라 접근합니다:
Nova Scotia Open Data — Open Government Licence – Nova Scotia v1.1에 따라 라이선스가 부여됩니다. Nova Scotia 주에서 제공하는 공공 부문 정보를 포함합니다.
Call a tool by name with the given arguments.
Use this to execute tools discovered via search_tools.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the tool to call | |
| arguments | No | Arguments to pass to the tool |
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.
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.
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.
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.
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.
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.
Search for tools using natural language.
Returns matching tool definitions ranked by relevance, in the same format as list_tools.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language query to search for tools |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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 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
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| calls | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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 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
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| query | Yes | ||
| top_k | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.7.0call_tooldiscover_toolsexecute_batchlist_modulesplan_queryTools 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.
All tool names follow a consistent verb_noun snake_case pattern (call_tool, discover_tools, execute_batch, list_modules, plan_query). No deviations.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for live public-data APIs and Skills for AI agents.
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
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