Loading ToolBench
CanLII MCP Server - When using scrape_website tool, always cite the source URL in your response for proper attribution and verification.
The server defines 5 tools for querying CanLII legal data. All tools have descriptions and input schemas with enum and string types. However, there are significant gaps: (1) descriptions are generic and lack actionable context for LLM selection; (2) many parameters lack individual descriptions (date filters repeat descriptions without clarifying their semantic purpose); (3) output schemas are not documented in the code, only input validation happens; (4) no error guidance or recovery paths are present; (5) tool names could be more specific (get_courts_and_tribunals is vague about whether it returns court details or just listings). The schemas are present but parameter descriptions are repetitive and do not explain when to use each date filter. This is a C-grade server with working tools but insufficient LLM optimization.
Browse legislation from a specific CanLII database by database ID with optional date filtering
Retrieve citation metadata for a case, including cases it cites, cases that cite it, or legislation it cites
Retrieves courts and tribunals from the CanLII case database with optional date filtering
Retrieve all available legislation databases with optional date filtering
Retrieve detailed metadata for a specific piece of legislation or regulation by ID
Output schemas are not documented. Code shows input validation with Zod schemas (CaseDatabasesResponseSchema, LegislationItemResponseSchema, etc.) but the actual field structure of these schemas is not visible in the provided source. LLMs cannot plan downstream operations or extract fields without knowing what the response contains.
Date filter parameters are repetitive and lack semantic clarity. All 5 tools include the same 8 date parameters (publishedBefore, publishedAfter, modifiedBefore, modifiedAfter, changedBefore, changedAfter, decisionDateBefore, decisionDateAfter) with identical descriptions. LLMs cannot distinguish when to use 'modified' vs 'changed' vs 'decision' dates without domain context. Descriptions should explain the semantic difference.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 56 | - | v1 |
Tool descriptions are under 100 characters and lack actionable context. Examples: 'Retrieves courts and tribunals from the CanLII case database with optional date filtering' (95 chars), 'Browse legislation from a specific CanLII database by database ID with optional date filtering' (98 chars). These describe WHAT but not WHEN to use, what the response contains, or how it differs from related tools. Per the rubric, descriptions should be 10 - 1024 chars with explicit WHAT/WHEN/prerequisites.
No error handling or recovery guidance. Error responses return generic messages like 'Error: Failed to fetch databases (${response.status})' with no actionable next step for the LLM. Per the rubric, errors must tell the LLM what to do next and categorize as retryable, user-fixable, or fatal.
Tool naming lacks specificity. 'get_courts_and_tribunals' combines two concepts and does not clarify whether it returns a list of available courts or detailed metadata. Per the rubric, names containing 'and' signal multiple responsibilities. Consider splitting into 'list_courts' + 'list_tribunals' or clarifying the distinction.
Pagination is not addressed. Tools that browse legislation or retrieve courts/tribunals may return large lists, but there is no visible limit parameter, page/offset support, or documentation of max results. Without pagination, large responses could exhaust context.
API key is injected via environment variable (env.CANLII_API) but there is no explicit documentation of this requirement in the server description or tool descriptions. A client deploying this server would not know to set CANLII_API without reading the code.