CanLII API를 통해 캐나다 법률 정보를 검색하기 위한 MCP(Model Context Protocol) 서버입니다. Claude Desktop 또는 Claude Code에서 바로 판례 검색, 법령 탐색, 인용 확인을 수행할 수 있습니다.
npx canlii-mcp전문 검색(Full-text search) — 키워드, 사건명 또는 법적 개념을 사용하여 CanLII 전체 검색
판례 인용 확인(Case citator) — 후속 판례에서 해당 사건을 어떻게 인용하는지 확인하여 현재 유효한 판례인지 검토
법령 탐색 — 관할 구역별 법률 및 규정 탐색
이중 언어 지원 — 인용 도구를 포함한 모든 도구에서 영어 및 프랑스어 지원
9가지 도구 — 검색, 법원 탐색, 판례 탐색, 판례 메타데이터, 전체 인용 정보, 인용 미리보기, 법령 데이터베이스, 법령 탐색, 법령 메타데이터
내장 속도 제한 — CanLII API 제한(초당 2회 요청, 동시 1회, 일일 5,000회)을 준수하는 직렬 요청 큐
입력 유효성 검사 — 모든 매개변수는 정규식 검증 및 URI 인코딩을 거쳐 인젝션 방지
최소한의 리소스 — 2개의 런타임 의존성, 약 500줄의 코드, 로컬 stdio 프로세스로 실행
보안 우선 — 파일 시스템 접근 불가, 셸 실행 불가, api.canlii.org에만 연결
Related MCP server: canlii-mcp
사전 요구 사항: Node.js 18+ 및 CanLII API 키 (연구용 무료).
Claude Desktop — 설정 파일에 추가 (~/Library/Application Support/Claude/claude_desktop_config.json macOS 기준):
{
"mcpServers": {
"canlii": {
"command": "npx",
"args": ["-y", "canlii-mcp"],
"env": {
"CANLII_API_KEY": "your_api_key_here"
}
}
}
}저장 후 Claude Desktop을 재시작하세요.
Claude Code:
claude mcp add canlii -e CANLII_API_KEY=your_key -- npx -y canlii-mcp소스에서 실행 (개발용):
git clone https://github.com/mohammadfarooqi/canlii-mcp.git
cd canlii-mcp
npm install && npm run buildCanLII 전체(판례, 법령, 주석)에 대한 전문 키워드 검색. 법률 연구의 기본 진입점입니다.
search({ query: "material change in circumstances Ontario", resultCount: 10 })사용 가능한 모든 법원 및 재판소 데이터베이스 목록을 나열합니다. 다른 도구에서 필요한 데이터베이스 ID를 반환합니다.
주요 온타리오 데이터베이스: onsc (고등법원), onca (항소법원), oncj (사법재판소), csc-scc (캐나다 대법원).
특정 법원 데이터베이스의 판례를 최근 추가된 순서대로 탐색합니다. 날짜 필터를 지원합니다.
get_case_law_decisions({ databaseId: "onsc", resultCount: 20 })특정 사건에 대한 전체 세부 정보(인용, 판결 날짜, 사건 번호, 키워드) 및 전체 판결문을 읽을 수 있는 CanLII URL을 가져옵니다.
get_case_metadata({ databaseId: "onsc", caseId: "2021onsc8582" })사건의 인용 관계를 조회합니다. citingCases를 사용하여 해당 사건이 여전히 유효한 판례인지 확인하세요.
get_case_citator({ databaseId: "csc-scc", caseId: "1996canlii190", metadataType: "citingCases" })최대 5개의 결과를 반환하는 빠른 인용 미리보기입니다. 전체 인용 도구보다 빠르게 확인할 때 유용합니다.
get_case_citator_tease({ databaseId: "csc-scc", caseId: "1996canlii190", metadataType: "citingCases" })모든 법령 데이터베이스를 나열합니다. 온타리오: ons (법률), onr (규정). 연방: cas (법률), car (규정).
특정 데이터베이스 내의 법령 항목을 나열합니다.
browse_legislation({ databaseId: "ons" })특정 법률 또는 규정에 대한 메타데이터(CanLII URL 포함)를 가져옵니다.
검색 — search({ query: "gatekeeping parenting time" })으로 관련 판례 찾기
세부 정보 확인 — get_case_metadata(...)로 전체 인용 및 CanLII URL 가져오기
인용 확인 — get_case_citator(..., metadataType: "citingCases")로 해당 판례가 여전히 유효한지 검증
판결문 읽기 — CanLII URL을 클릭하여 canlii.org에서 전문 읽기
CanLII API 약관에 따름:
일일 5,000회 쿼리
초당 2회 요청
한 번에 1회 요청
메타데이터 접근만 가능 — 전체 문서 텍스트는 API를 통해 제공되지 않음
서버는 내장된 속도 제한기를 통해 이러한 제한을 자동으로 준수합니다.
npm run build # Compile TypeScript
npm run start # Run the server (needs CANLII_API_KEY env var)src/
index.ts # MCP server — tools, rate limiter, stdio transport
schema.ts # Zod schemas for CanLII API responses기여를 환영합니다! 이 프로젝트는 AI 도구를 통해 캐나다 법률 연구를 더 쉽게 만드는 것을 목표로 합니다.
기여 방법:
PR 제출 방법:
이 저장소를 포크(Fork)합니다.
기능 브랜치를 생성합니다 (git checkout -b feature/my-improvement).
변경 사항을 적용하고 로컬에서 테스트합니다 (npm run build && CANLII_API_KEY=your_key npm run start).
커밋하고 포크한 저장소에 푸시합니다.
변경 내용과 이유를 설명하는 풀 리퀘스트를 엽니다.
CanLII API 응답 문제, 스키마 불일치 또는 법률 연구에 도움이 될 새로운 도구 아이디어가 있다면 해결 방법을 모르더라도 이슈를 열어주세요. 함께 조사하겠습니다.
이 서버는 투명하고 최소한의 기능으로 설계되었습니다:
api.canlii.org에만 연결 — 다른 네트워크 호출, 텔레메트리, 분석 도구 없음
API 키는 로컬에 유지 — 환경 변수를 통해 전달되며, 로그에 남거나 응답에 포함되지 않음
모든 입력값 검증 — 데이터베이스 ID, 사건 ID, 날짜는 사용 전 정규식 검증을 거치며, 경로 세그먼트는 URI 인코딩됨
모든 API 응답 검증 — 반환 전 Zod 스키마를 통해 파싱
파일 시스템 접근 불가 — 서버는 CanLII에 대한 HTTPS 호출만 수행
셸 실행 불가 — child_process, exec, spawn 사용 안 함
2개의 런타임 의존성 — @modelcontextprotocol/sdk (공식 Anthropic MCP SDK) 및 zod (스키마 검증)
내장 속도 제한 — 직렬 요청 큐를 통해 API 남용 방지
MIT 라이선스, 완전 오픈 소스 — src/index.ts(약 350줄) 및 src/schema.ts(약 140줄)에서 모든 코드 확인 가능
보안 문제를 발견하시면 SECURITY.md를 참조하세요.
판결문 본문 없음 — 전문 검색은 가능하지만(사건 제목, 인용, 내용 검색), API는 판결문 전문을 반환할 수 없습니다. canlii.org에서 판결문을 읽으려면 CanLII URL을 클릭해야 합니다. 단락 번호와 직접 인용은 원문을 읽고 확인해야 합니다.
키워드 기반 검색 — 의미론적 검색이 아니므로 "mother gatekeeping sole decision-making"과 같은 쿼리는 혼합된 결과를 반환할 수 있습니다. 쿼리를 구체화하고 메타데이터를 확인하기 전에 사건 제목을 먼저 확인하세요.
검색 결과에 사건 세부 정보 미포함 — 검색 결과는 인용과 제목만 반환합니다. 키워드, 주제, 판결 날짜, CanLII URL을 얻으려면 각 사건에 대해 get_case_metadata를 별도로 호출해야 합니다.
처리 지표 없음 — 인용 도구는 어떤 사건이 해당 판결을 인용하는지 보여주지만, 인용된 판결이 따랐는지, 구별되었는지, 뒤집혔는지 여부는 나타내지 않습니다. 인용된 판례를 읽고 처리 여부를 판단해야 합니다.
인용 미리보기는 최대 5개 결과 — 포괄적인 인용 분석을 위해서는 get_case_citator(전체 버전)를 사용하세요.
검색 시 데이터베이스/관할 구역 필터 없음 — 서버 측에서 특정 법원이나 주(province)로 검색 결과를 제한할 수 없습니다. 대신 쿼리에 관할 구역 키워드를 추가하세요 (예: "custody" 대신 "custody Ontario").
검색 엔드포인트는 비공식 — 작동은 하지만 CanLII 공식 API 문서에 없으므로 예고 없이 변경될 수 있습니다.
엄격한 속도 제한 — 일일 5,000회 쿼리, 초당 2회 요청, 동시 1회 요청(내장 속도 제한기에 의해 자동 강제).
MIT — LICENSE 참조.
List all legislation items in a specific database. Use to find legislation IDs for metadata lookup. Key statutes by database — ons: Children's Law Reform Act, Family Law Act, Employment Standards Act. cas: Divorce Act, Criminal Code, Canada Labour Code, Federal Child Support Guidelines.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language: 'en' for English (default), 'fr' for French | en |
| databaseId | Yes | Legislation database ID (e.g., 'ons' for Ontario Statutes, 'cas' for Canada Statutes, 'onr' for Ontario Regulations) | |
| publishedBefore | No | Date first published on CanLII (YYYY-MM-DD) | |
| publishedAfter | No | Date first published on CanLII (YYYY-MM-DD) | |
| modifiedBefore | No | Date content last modified on CanLII (YYYY-MM-DD) | |
| modifiedAfter | No | Date content last modified on CanLII (YYYY-MM-DD) | |
| changedBefore | No | Date metadata or content last changed on CanLII (YYYY-MM-DD) | |
| changedAfter | No | Date metadata or content last changed on CanLII (YYYY-MM-DD) | |
| decisionDateBefore | No | Decision date upper bound (YYYY-MM-DD) | |
| decisionDateAfter | No | Decision date lower bound (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as pagination, rate limits, or output size. For a listing tool, this 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?
Three focused sentences: purpose, use case, and examples. No redundant information; every sentence is necessary.
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 10 parameters and no output schema, the description is adequate but lacks details on how filters interact, output format, or pagination. Suitable for a basic list tool but not fully complete.
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 coverage is 100%, but the description adds value by listing key statutes per database (e.g., 'ons: Children's Law Reform Act'), helping agents select the correct databaseId. This goes beyond the schema's pattern description.
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 lists all legislation items in a specific database and is used to find legislation IDs for metadata lookup. It distinguishes from sibling tools which focus on case law.
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 specifies using the tool to find legislation IDs, but does not explicitly state when not to use it or compare to the sibling 'search' tool. The context is clear enough for legislation-specific tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up citation relationships for a case. Critical for verifying if a case is still good law. Use 'citingCases' to see what later cases cite this decision — if many recent cases cite it approvingly, it is strong authority. Use 'citedCases' to see what authorities this case relied on. Use 'citedLegislations' to see what statutes the case references. Returns the full list of citing/cited items.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language: 'en' for English (default), 'fr' for French | en |
| databaseId | Yes | Court database ID (e.g., 'onsc', 'onca', 'csc-scc') | |
| caseId | Yes | Case unique identifier (e.g., '2021onsc8582') | |
| metadataType | Yes | 'citingCases' = what later cases cite this one (check if still good law); 'citedCases' = what this case relies on; 'citedLegislations' = statutes referenced | |
| publishedBefore | No | Date first published on CanLII (YYYY-MM-DD) | |
| publishedAfter | No | Date first published on CanLII (YYYY-MM-DD) | |
| modifiedBefore | No | Date content last modified on CanLII (YYYY-MM-DD) | |
| modifiedAfter | No | Date content last modified on CanLII (YYYY-MM-DD) | |
| changedBefore | No | Date metadata or content last changed on CanLII (YYYY-MM-DD) | |
| changedAfter | No | Date metadata or content last changed on CanLII (YYYY-MM-DD) | |
| decisionDateBefore | No | Decision date upper bound (YYYY-MM-DD) | |
| decisionDateAfter | No | Decision date lower bound (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states 'Returns the full list of citing/cited items,' which implies a complete list without pagination. However, it does not cover potential limits, error handling, authentication needs, or response structure. For a read-only lookup tool, this is adequate but lacks depth.
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 a single paragraph of four sentences, front-loaded with the core purpose. Every sentence provides useful information without unnecessary words. It is highly concise and well-structured for quick comprehension.
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 has 12 parameters (mostly optional date filters) and no output schema, the description focuses on the essential use cases and the returned item list. It covers the critical metadataType options and the tool's importance. However, it does not mention the filtering capabilities or language parameter, which are documented in the schema but not in the description. Overall, it is sufficiently complete for an AI agent to understand the tool's core functionality.
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?
Input schema has 100% description coverage, providing clear meaning for all parameters. The description adds value by explaining the semantic intent of metadataType and the overall workflow, e.g., 'use 'citingCases' to see what later cases cite this decision.' It does not repeat parameter descriptions but enhances understanding, going beyond the baseline 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 tool's purpose: 'Look up citation relationships for a case.' It specifies the three metadataType values and their meanings (citingCases, citedCases, citedLegislations), making the tool's function very specific and distinguishable from siblings like get_case_citator_tease, though not explicitly differentiating.
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 provides clear guidance on when to use each metadataType: 'Use 'citingCases' to see what later cases cite this decision... Use 'citedCases' to see what authorities this case relied on. Use 'citedLegislations' to see what statutes the case references.' It frames the tool as 'critical for verifying if a case is still good law,' but does not mention when not to use it or how it compares to the sibling get_case_citator_tease.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quick preview of citation relationships (max 5 results). Faster than the full citator. Use this for a quick check on whether a case has been cited, then use get_case_citator for the complete list if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language: 'en' for English (default), 'fr' for French | en |
| databaseId | Yes | Court database ID (e.g., 'onsc', 'onca', 'csc-scc') | |
| caseId | Yes | Case unique identifier (e.g., '2021onsc8582') | |
| metadataType | Yes | Type of citation data to preview |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the key behavioral trait of returning at most 5 results and being faster than the full citator. However, with no annotations provided, it does not cover other traits like authentication requirements or error handling, which would be valuable for a write operation but this is a read-only preview.
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?
Extremely concise with two sentences that convey purpose, limits, speed advantage, and recommended workflow. No redundant information.
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 explains the tool's role and limits but does not describe the output format or behavior beyond the preview, leaving some ambiguity for an agent. However, given the simplicity of the tool and the absence of an output schema, it is minimally adequate.
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 100%, with each parameter already well-described in the schema. The description adds no further parameter-level detail beyond the tool's overall purpose, so it aligns with the baseline score.
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?
Clearly states the tool provides a quick preview of citation relationships with a maximum of 5 results, distinguishing it from the sibling 'get_case_citator' which offers the complete list.
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?
Explicitly tells when to use this tool ('quick check') and advises to use the full citator for a complete list if needed, providing clear usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List case law decisions from a specific court database. Use date filters to narrow results. Useful for browsing recent decisions from a specific court. Results are ordered by most recently added. Use get_case_metadata to get full details on a specific case.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language: 'en' for English (default), 'fr' for French | en |
| databaseId | Yes | Court database ID (e.g., 'onsc' for Ontario Superior Court, 'onca' for Ontario Court of Appeal, 'csc-scc' for Supreme Court of Canada) | |
| offset | No | Start position for results (default 0 = most recent) | |
| resultCount | No | Number of results to return (max 10,000, default 20) | |
| publishedBefore | No | Date first published on CanLII (YYYY-MM-DD) | |
| publishedAfter | No | Date first published on CanLII (YYYY-MM-DD) | |
| modifiedBefore | No | Date content last modified on CanLII (YYYY-MM-DD) | |
| modifiedAfter | No | Date content last modified on CanLII (YYYY-MM-DD) | |
| changedBefore | No | Date metadata or content last changed on CanLII (YYYY-MM-DD) | |
| changedAfter | No | Date metadata or content last changed on CanLII (YYYY-MM-DD) | |
| decisionDateBefore | No | Decision date upper bound (YYYY-MM-DD) | |
| decisionDateAfter | No | Decision date lower bound (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that results are ordered by most recently added, which is key behavior. However, it does not mention any potential side effects, authorization needs, or rate limits.
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?
Two efficient sentences that front-load the main purpose and add relevant usage context. Could be slightly more structured, but overall concise.
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 12 parameters (all documented in schema) and no output schema, the description sufficiently explains the tool's purpose, ordering, and relationship to sibling tools. References get_case_metadata for full details, which helps complete the picture.
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 coverage is 100% with clear parameter descriptions. The description adds high-level purpose but does not provide additional meaning beyond what the schema already specifies for parameters.
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?
Description clearly states the tool lists case law decisions from a specific court database, with date filtering capabilities. It explicitly distinguishes from the sibling tool get_case_metadata, which provides full details on a specific case.
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 clear context for use (browsing recent decisions from a specific court) and mentions an alternative tool (get_case_metadata) for full details. However, it does not explicitly mention when not to use this tool or other alternatives like 'search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed metadata for a specific case including its CanLII URL, citation, decision date, docket number, keywords, and topics. The URL field links directly to the full decision text on canlii.org — always provide this to the user for verification. Use after finding a case via search or browse to get complete details before citing it.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language: 'en' for English (default), 'fr' for French | en |
| databaseId | Yes | Court database ID (e.g., 'onsc', 'onca', 'csc-scc') | |
| caseId | Yes | Case unique identifier from search/browse results (e.g., '2021onsc8582') | |
| publishedBefore | No | Date first published on CanLII (YYYY-MM-DD) | |
| publishedAfter | No | Date first published on CanLII (YYYY-MM-DD) | |
| modifiedBefore | No | Date content last modified on CanLII (YYYY-MM-DD) | |
| modifiedAfter | No | Date content last modified on CanLII (YYYY-MM-DD) | |
| changedBefore | No | Date metadata or content last changed on CanLII (YYYY-MM-DD) | |
| changedAfter | No | Date metadata or content last changed on CanLII (YYYY-MM-DD) | |
| decisionDateBefore | No | Decision date upper bound (YYYY-MM-DD) | |
| decisionDateAfter | No | Decision date lower bound (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the tool is a read-like retrieval (getting metadata) and includes an instruction to always provide the URL to the user. However, it does not explicitly state it is read-only or mention any permissions or side effects, which weakens transparency.
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 concise sentences. The first states the purpose and output; the second gives usage guidance. Every word adds value, and the structure is front-loaded with the most critical information.
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 lists key output fields, providing enough context for an agent to understand return structure despite no output schema. It does not explain all parameters or potential errors, but for a simple retrieval tool, it is complete enough.
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 100%, so each parameter already has a description. The tool description adds no additional meaning beyond schema, except implying that databaseId and caseId are central. This meets the baseline 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 uses the specific verb 'Get' and targets 'detailed metadata for a specific case'. It lists key outputs (CanLII URL, citation, etc.) and differentiates the tool from search and browsing by stating it provides complete details before citing.
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 tool 'after finding a case via search or browse to get complete details before citing it'. This provides clear context for when to invoke it, though it does not explicitly mention when not to use it or name specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available court and tribunal databases in Canada. Returns database IDs needed for other tools. Key databases: onsc (Ontario Superior Court), onca (Ontario Court of Appeal), oncj (Ontario Court of Justice), onscdc (Divisional Court), csc-scc (Supreme Court of Canada), bcsc (BC Supreme Court), abkb (Alberta King's Bench). Use this to discover valid databaseId values for browse and citator tools.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language: 'en' for English (default), 'fr' for French | en |
| publishedBefore | No | Date first published on CanLII (YYYY-MM-DD) | |
| publishedAfter | No | Date first published on CanLII (YYYY-MM-DD) | |
| modifiedBefore | No | Date content last modified on CanLII (YYYY-MM-DD) | |
| modifiedAfter | No | Date content last modified on CanLII (YYYY-MM-DD) | |
| changedBefore | No | Date metadata or content last changed on CanLII (YYYY-MM-DD) | |
| changedAfter | No | Date metadata or content last changed on CanLII (YYYY-MM-DD) | |
| decisionDateBefore | No | Decision date upper bound (YYYY-MM-DD) | |
| decisionDateAfter | No | Decision date lower bound (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Though no annotations are provided, the description implies a read-only operation (listing databases) and explicitly states it returns database IDs. It does not contradict any annotations.
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 concise, using three sentences to convey purpose, examples, and usage guidance. Slightly verbose with examples but overall efficient.
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 and no output schema, the description covers the core purpose and return values. It does not detail the return structure but is sufficient for a listing 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?
All 9 parameters are fully described in the input schema (100% coverage). The description does not add additional meaning beyond the schema, meriting 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 tool lists all available court and tribunal databases in Canada and returns database IDs needed for other tools. It distinguishes itself from siblings like get_legislation_databases by specifying it provides database IDs for browse and citator tools.
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 advises using this tool to discover valid databaseId values for browse and citator tools, providing clear guidance on when to use. However, it does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available legislation databases in Canada. Returns database IDs for browsing statutes and regulations. Key databases: ons (Ontario Statutes), onr (Ontario Regulations), cas (Canada Statutes), car (Canada Regulations), bcs (BC Statutes), abs (Alberta Statutes).
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language: 'en' for English (default), 'fr' for French | en |
| publishedBefore | No | Date first published on CanLII (YYYY-MM-DD) | |
| publishedAfter | No | Date first published on CanLII (YYYY-MM-DD) | |
| modifiedBefore | No | Date content last modified on CanLII (YYYY-MM-DD) | |
| modifiedAfter | No | Date content last modified on CanLII (YYYY-MM-DD) | |
| changedBefore | No | Date metadata or content last changed on CanLII (YYYY-MM-DD) | |
| changedAfter | No | Date metadata or content last changed on CanLII (YYYY-MM-DD) | |
| decisionDateBefore | No | Decision date upper bound (YYYY-MM-DD) | |
| decisionDateAfter | No | Decision date lower bound (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns database IDs and lists key databases, but it does not disclose behavioral traits such as read-only nature, rate limits, or any side effects. For a simple listing tool, this is adequate but not exhaustive.
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 extremely concise: two sentences plus a brief list of key databases. It is front-loaded with the purpose and provides immediate value without unnecessary detail.
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 tool has 9 optional filter parameters, but the description does not explain their purpose or how to use them effectively. There is no output schema, and the description only mentions 'returns database IDs' without specifying format or structure. This leaves some gaps, but for a simple listing tool it is minimally adequate.
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, so the baseline is 3. The description does not add meaning beyond the schema; it only mentions database IDs in the output context. The parameters are well-documented in the schema, so no further elaboration is needed.
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's function: listing all available legislation databases in Canada. It provides specific examples of key databases and what they represent. This distinguishes it from sibling tools like browse_legislation or get_case_citator.
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 indicates the tool is for retrieving a list of databases, which is a clear use case. It does not explicitly mention when not to use it or provide alternatives, but the context is sufficient for an AI agent to understand its primary role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for a specific statute or regulation including its CanLII URL, citation, and table of contents. The URL links directly to the full legislation text on canlii.org — always provide this to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language: 'en' for English (default), 'fr' for French | en |
| databaseId | Yes | Legislation database ID (e.g., 'ons' for Ontario Statutes) | |
| legislationId | Yes | Specific legislation ID from browse results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It reveals what is returned but does not disclose that it is read-only, any side effects, permissions, or rate limits.
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?
Two sentences: first states purpose and content, second provides actionable instruction. No wasted words, information is front-loaded.
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 and absence of output schema, the description adequately covers the return content and user instruction. However, it could mention that the IDs come from browse results.
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?
Input schema has 100% description coverage, so the description adds minimal extra meaning beyond the schema's field descriptions. The mention of 'CanLII URL, citation, and table of contents' provides general context but not parameter details.
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 retrieves metadata for a specific statute/regulation, including URL, citation, and table of contents, distinguishing it from sibling tools like browse_legislation.
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 usage (when you need metadata for a specific legislation), but does not provide explicit guidance on when to prefer this over siblings or exclude certain cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search CanLII for cases, legislation, and commentary by keyword. This is the primary entry point for legal research. Returns case citations and titles ranked by relevance — does NOT include keywords, dates, or URLs. Call get_case_metadata on promising results to get full details before citing a case. Search is keyword-based, not semantic — use specific legal terms rather than natural language. Common terms: 'best interests of the child', 'material change in circumstances', 'standard of review', 'duty to consult', 'reasonable expectation of privacy'. Include jurisdiction to narrow results (e.g., 'Ontario', 'Alberta'). Date filters are NOT supported on search. Always cite the CanLII citation and provide the case URL so the user can verify the source.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Full-text search query. Can include case names, legal concepts, legislation references, or keywords. | |
| language | No | Language: 'en' for English (default), 'fr' for French | en |
| resultCount | No | Number of results to return (1-100, default 10). Keep low for AI context efficiency. | |
| offset | No | Pagination offset (default 0). Use to page through results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description fully compensates for missing annotations by disclosing return content (citations and titles only, not keywords/dates/URLs), search nature (keyword-based), limitations (no date filters), and recommended follow-up. No contradictions.
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?
Description is a single paragraph that covers all needed information without wasted words. Could be more structured with bullets, but each sentence adds value and it remains readable.
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 no output schema and no annotations, the description provides sufficient context: input, behavior, limitations, and workflow. It covers what the tool returns and what it does not, and directs the agent to next steps. Could mention error handling or permissions, but is 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?
Schema coverage is 100%, so baseline is 3. Description adds value by noting 'keep low for AI context efficiency' for resultCount, and explaining that query should include jurisdiction to narrow. These go beyond schema field descriptions.
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?
Description clearly states the tool searches CanLII for cases, legislation, and commentary by keyword, and positions it as the primary entry point for legal research. However, it does not explicitly differentiate from sibling tools like browse_legislation or get_case_metadata, though it implies they are for follow-up after search.
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 when-to-use guidance: 'primary entry point' and after search, 'call get_case_metadata on promising results'. Also explains search is keyword-based, not semantic, and advises including jurisdiction. Does not explicitly list situations where other tools are better, but the workflow is clear.
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.
v1.1.4browse_legislationget_case_citatorget_case_citator_teaseget_case_law_decisionsget_case_metadataget_courts_and_tribunalsget_legislation_databasesget_legislation_regulation_metadatasearchScored across 9 tools
Each tool has a distinct purpose: browse_legislation lists legislation items, get_case_citator retrieves full citation relationships, get_case_citator_tease offers a quick preview, get_case_law_decisions lists decisions from a court database, get_case_metadata provides detailed case info, get_courts_and_tribunals lists available court databases, get_legislation_databases lists legislation databases, get_legislation_regulation_metadata fetches legislation details, and search performs keyword searches. No two tools overlap significantly.
Most tools follow a 'get_' prefix (e.g., get_case_metadata, get_courts_and_tribunals), but 'browse_legislation' uses 'browse_' and 'search' is a bare verb. This slight inconsistency is minor and does not hinder readability.
Nine tools is appropriate for a legal research server. Each tool covers a core function—searching, browsing cases and legislation, citators, and metadata retrieval—without being excessive or insufficient.
The surface covers essential read-only legal research operations: search, browse, citator, and metadata. Minor gaps include lack of date filters on search (mitigated by jurisdiction keywords) and no direct full-text retrieval (URLs provided instead). Overall, it's well-rounded.
MCP for CanLII: Canadian case law and legislation metadata (federal, provincial, territorial).
Resolve, search and verify legal citations against the official sources, with provenance.
Korean law: statutes, precedents, ordinances, treaties and citation verification (법제처 API).
Wrapper for the official LegalOne API (Thomson Reuters / Novajus, Premium package): lawsuits and lit
