Skip to main content
Glama
yvesnormandin

CanLII MCP Server

by yvesnormandin
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

CanLII MCP Server

A local Model Context Protocol (MCP) server for macOS that lets Claude Desktop search the CanLII Canadian legal database and read the full text of matching documents.

What it does

Exposes a single MCP tool — search_canlii — that Claude can call to:

  1. Search CanLII using either full-text or case-name search

  2. Fetch the full text of the top matching documents

  3. Return cleaned plain text (no HTML markup) back to Claude

Related MCP server: canlii-mcp

Tool reference

search_canlii(
    query: str,
    search_type: "text" | "name" = "text",
    max_results: int = 5   # 1–10
)

search_type

When to use

"text"

Legal concepts, keywords, or phrases within judgment bodies

"name"

Case name, document title, file number, author, or citation (e.g. R v Oakes, 2024 SCC 12)

Requirements

Installation

1. Clone the repository

git clone <repo-url>
cd canlii_mcp_server

2. Install dependencies and Chromium

uv sync
uv run playwright install chromium

3. Add the server to Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "canlii": {
      "command": "/path/to/uv",
      "args": [
        "run",
        "--project",
        "/path/to/canlii_mcp_server",
        "canlii-mcp-server"
      ]
    }
  }
}

Replace /path/to/uv with the output of which uv, and /path/to/canlii_mcp_server with the absolute path to this directory.

4. Restart Claude Desktop

Fully quit Claude Desktop (menu bar → Quit), then reopen it. The canlii server will appear under Settings → Developer.

Usage

In a Claude Desktop conversation:

"Search CanLII for cases about reasonable apprehension of bias."

"Find the case R v Oakes."

"What does CanLII say about the duty to accommodate in employment law?"

Claude will call search_canlii automatically with the appropriate search_type.

How it works

CanLII's website is a JavaScript single-page application — search results are rendered client-side and not available in raw HTML. This server uses Playwright (headless Chromium) to load pages as a real browser would, then extracts clean text with BeautifulSoup.

playwright-stealth is applied to each page load to reduce the likelihood of bot detection by CanLII's DataDome protection. Requests are rate-limited to 1.5 seconds between document fetches to avoid triggering blocks.

Note: CanLII's bot protection may occasionally flag automated requests. If Claude reports a "blocked" error, wait an hour and try again.

Development

Run unit tests

uv run pytest tests/ --ignore=tests/test_smoke.py -v

Run live integration tests (requires network access to canlii.org)

uv run pytest tests/test_smoke.py -v -s

Project structure

src/canlii_mcp_server/
    server.py   — MCP server entry point, tool registration
    search.py   — URL builder, search results parser
    fetch.py    — document text extractor, Playwright browser manager
tests/
    test_url_builder.py        — URL building (5 tests)
    test_search_parser.py      — search results parsing (4 tests)
    test_document_extractor.py — document text extraction (5 tests)
    test_smoke.py              — live integration tests (3 tests, manual)
    fixtures/                  — saved CanLII HTML used by unit tests
scripts/
    recon.py           — captures CanLII HTML structure for fixture updates
    recon_document.py  — captures a single document page slowly

Limitations

  • No full-text API: CanLII does not provide an API that returns document text — only metadata. Playwright scraping is the only viable approach.

  • Bot detection: CanLII uses DataDome. Occasional temporary blocks are possible.

  • No noteup search: CanLII's "Noteup/Discussion" search requires a document path as input rather than a free-text query. This search type is not currently supported.

  • English only: The server searches the English index (indexLang=en).

License

MIT

Available Tools

1 tool
search_canliiA

Search the CanLII Canadian legal database and return the full text of matching documents.

search_type values:

  • 'text': full-text search within document bodies — use for legal concepts, keywords, or phrases in judgments

  • 'name': search by case name, document title, file number, author, or citation — use for 'R v Oakes' or '2024 SCC 12'

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe search query
max_resultsNoNumber of documents to fetch and return
search_typeNoWhich CanLII search box to usetext

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries the transparency burden. It discloses that the tool returns full text and explains the two search modes, but it does not mention limitations such as result ordering, pagination, rate limits, or explicitly confirm that the operation is read-only.

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 compact and well-structured: one opening sentence defining the core function, followed by a clear, bullet-like breakdown of search_type values. Every sentence earns its place with no 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?

For a simple search tool with a fully described schema, the description is almost complete. It specifies the return behavior (full text) and mode-specific use cases. Minor gaps include no mention of result format beyond 'full text' or error handling, but these are not critical given the schema coverage.

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?

The schema covers all parameters, so the baseline is 3. The description adds meaningful context beyond the schema, especially for search_type with concrete use cases and examples, making parameter selection more accurate.

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 the CanLII Canadian legal database and returns full-text documents. The explicit breakdown of search_type values with examples (legal concepts vs case names/citations) leaves no ambiguity about the tool's function.

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 provides explicit when-to-use guidance for each search_type mode ('use for legal concepts...' vs 'use for R v Oakes'), which helps the agent select the correct mode. However, it does not discuss alternatives to the tool itself or cases where the tool should not be used.

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

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

TDQS

A4.4/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of ambiguity or confusion between tools. The tool's purpose is clear and singular.

Naming Consistency5/5

With a single tool, naming consistency is trivially satisfied. 'search_canlii' follows a clear verb_noun pattern and is descriptive.

Tool Count4/5

One tool is minimal but perfectly suited to the narrow purpose of searching the CanLII database. While the typical range is higher, this tool fully covers the intended functionality without being trivial.

Completeness5/5

The search tool provides two essential search modes (text and name) and returns full document text, effectively covering both discovery and retrieval. For a search-only server, this is a complete surface with no obvious dead ends.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Claude RAG MCP Pipeline

    kenjisekino
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables Claude Desktop to search and query personal document collections (PDF, Word, Markdown, text) using semantic search and conversational AI with full context preservation across exchanges.
    MIT

  • canlii-mcp

    Alhwyn
    A
    license
    Not graded
    quality
    C
    maintenance
    Provides access to the CanLII API for searching and retrieving Canadian legal information, including court decisions, legislation, and citations.
    23
    MIT

  • LegalContext

    protomated
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables secure access to legal documents from Clio via Claude Desktop, with local processing and semantic search to ground AI responses in actual documents.
    30
    29
    Mozilla Public 2.0

Latest Blog Posts

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/yvesnormandin/canlii_mcp_server'

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