What can you do with this server?

This server gives AI assistants access to Canadian legal case law and legislation metadata across all federal, provincial, and territorial jurisdictions via the CanLII API. Note: full document text is not available — only metadata (titles, citations, dates, keywords, citation relationships). Capabilities: * List case databases — Retrieve all courts and tribunals in the CanLII collection, including their database IDs (list_case_databases) * Browse cases — List decisions from a specific court/tribunal with optional date range filters, pagination, and result count control (list_cases) * Get case metadata — Retrieve a case's title, citation, decision date, keywords, and URL (get_case) * Explore citation relationships — Find cases a given case cites, cases that cite it, or legislation it references (get_case_citations; currently English only) * List legislation databases — Retrieve all statute and regulation databases available in CanLII (list_legislation_databases) * Browse legislation — List statutes or regulations from a specific database (list_legislation) * Get legislation metadata — Retrieve a statute's or regulation's title, citation, dates, and repeal status (get_legislation) Most tools support both English and French language responses where available.

How do I use canlii-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@canlii-mcp search for cases citing R v Oakes" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

canlii-mcp

by Vaquill-AI

Overview Schema Related Servers Score Discussions

TypeScript

Remote

canlii-mcp

An MCP (Model Context Protocol) server for the CanLII Canadian legal information API. Gives AI assistants access to Canadian case law and legislation metadata across all federal, provincial, and territorial jurisdictions.

Forked from tomilashy/canlii-mcp. This fork adds bring-your-own-key (BYOK) auth, a /health route, and a hosted endpoint at canlii-mcp.vaquill.ai. Tools are unchanged.

Note: The CanLII API provides metadata only — titles, citations, dates, keywords, and citation relationships. Full document text is not available through the API.

Use the hosted endpoint (no install)

https://canlii-mcp.vaquill.ai/mcp

The hosted instance is public. No Vaquill token is required. Provide your own CanLII key one of two ways:

Header (recommended, keeps the key out of the URL): X-CanLII-Token: <your_canlii_api_key>
URL parameter (simplest; works in header-less clients like the Claude Desktop connector UI and claude.ai web): append ?token=<your_canlii_api_key> to the URL:
```
https://canlii-mcp.vaquill.ai/mcp?token=YOUR_CANLII_API_KEY
```

Apply for a key at canlii.org/en/api/. The server never stores your key, and there is no server-side fallback key, so every call counts against your own CanLII quota.

Claude Desktop / Claude Code

{
  "mcpServers": {
    "canlii": {
      "url": "https://canlii-mcp.vaquill.ai/mcp",
      "headers": {
        "X-CanLII-Token": "YOUR_CANLII_API_KEY"
      }
    }
  }
}

Cursor / VS Code / Windsurf

Same pattern: any client supporting MCP streamable HTTP with custom headers works. For stdio-only clients use mcp-remote to proxy.

Related MCP server: courtlistener-mcp

Authentication

Mode	Header	When
BYOK header (preferred)	`X-CanLII-Token: <key>`	Hosted / shared deployments
BYOK URL param	`?token=<key>` (or `?canlii_token=`)	Header-less clients: Claude Desktop connector UI, claude.ai web
Server fallback	(env `CANLII_API`)	Self-hosted single-tenant. Required for stdio.
MCP gate	`Authorization: Bearer <MCP_AUTH_TOKEN>`	Optional, self-host only. The public hosted endpoint at `canlii-mcp.vaquill.ai` does not use it, so no bearer token is required.

Tools

Tool	Description
`list_case_databases`	List all courts and tribunals in the CanLII collection
`list_cases`	Browse decisions from a specific court/tribunal database
`get_case`	Get metadata for a specific case (title, citation, date, keywords)
`get_case_citations`	Get cases cited by a case, cases citing it, or legislation it references
`list_legislation_databases`	List all statute and regulation databases
`list_legislation`	Browse statutes or regulations from a specific database
`get_legislation`	Get metadata for a specific piece of legislation

Requirements

Node.js 22+
A CanLII API key — apply here

Usage

stdio via npx (quickest)

{
  "mcpServers": {
    "canlii": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@tomilashy/canlii-mcp"],
      "env": {
        "CANLII_API": "your_api_key"
      }
    }
  }
}

stdio (from source)

npm install
npm run build
node dist/index.js

Add to your MCP config:

{
  "mcpServers": {
    "canlii": {
      "command": "node",
      "args": ["/path/to/canlii-mcp/dist/index.js"],
      "env": {
        "CANLII_API": "your_api_key"
      }
    }
  }
}

HTTP server

PORT=3000 CANLII_API=your_api_key node dist/index.js --transport http

The MCP endpoint is available at http://localhost:3000/mcp. The server runs in stateless mode — each request is self-contained, no session ID or initialize handshake required. Clients can call tools directly:

curl -X POST http://localhost:3000/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_case_databases","arguments":{"language":"en"}}}'

Docker

docker run -e CANLII_API=your_api_key -e MCP_AUTH_TOKEN=your_secret -p 3000:3000 ghcr.io/tomilashy/canlii-mcp

Or with Docker Compose:

services:
  canlii-mcp:
    image: ghcr.io/tomilashy/canlii-mcp
    environment:
      CANLII_API: your_api_key
      MCP_AUTH_TOKEN: your_secret  # optional
    ports:
      - "3000:3000"

Cloudflare Workers

The server includes a Workers-compatible entry point (src/worker.ts).

CLI deploy

npx wrangler secret put CANLII_API
npx wrangler secret put MCP_AUTH_TOKEN  # optional
npx wrangler deploy

Dashboard deploy (Connect to Git)

Go to Cloudflare Dashboard → Workers & Pages → Create → Connect to Git
Select your tomilashy/canlii-mcp repository
On the Set up your application page:
- Project name: canlii-mcp
- Build command: npm install && npm run build
- Deploy command: npx wrangler deploy (pre-filled)
Expand Advanced settings:
- Variable name: CANLII_API
- Variable value: your CanLII API key
- Check Encrypt to store it as a secret
Click Deploy

The MCP endpoint will be at https://canlii-mcp.<your-subdomain>.workers.dev/mcp.

Configuration

Environment Variable	Required	Default	Description
`CANLII_API`	Yes	—	Your CanLII API key
`PORT`	No	`3000`	HTTP server port (HTTP mode only)
`MCP_AUTH_TOKEN`	No	—	Bearer token for HTTP authentication. If set, all HTTP requests must include `Authorization: Bearer <token>`. If not set, the server runs without authentication.

Rate Limits

The server enforces CanLII's API limits automatically, per CanLII key, so one caller's usage never throttles another's:

1 request at a time
2 requests per second
5,000 requests per day

These mirror CanLII's own per-key limits. Each X-CanLII-Token gets its own independent budget (keyed by a hash of the key; raw keys are never retained). Requests that exceed the daily limit return an error rather than hitting the API.

Development

npm install
npm run build      # compile TypeScript
npm run watch      # watch mode

Release

This project uses Semantic Versioning via semantic-release. Commit messages follow the Conventional Commits spec:

Commit prefix	Release type
`fix:`	Patch (`1.0.0` → `1.0.1`)
`feat:`	Minor (`1.0.0` → `1.1.0`)
`feat!:` or `BREAKING CHANGE`	Major (`1.0.0` → `2.0.0`)

Pushing to main triggers the release workflow. If a release is cut, the Docker image is automatically built and published to ghcr.io.

License

MIT

Available Tools

7 tools

get_caseGet CaseA

Read-only

Inspect

Get metadata for a specific case including title, citation, decision date, keywords, and URL.

ParametersJSON Schema

Name	Required	Description	Default
`caseId`	Yes	Case ID from list_cases (e.g. "2008scc9")
`databaseId`	Yes	Database ID (e.g. "csc-scc")
`language`	No	Response language	en

TDQS

A4/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true. The description adds that it returns specific metadata fields, which is consistent and provides additional context beyond the annotation.

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?

Single sentence, front-loaded with the action and resource, no wasted words. Efficient and clear.

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?

The tool is simple with no output schema. The description lists return fields, and the schema fully documents parameters. This is sufficient for a straightforward read operation.

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?

Schema description coverage is 100%, so the schema already documents all parameters. The description does not add meaning to parameters (e.g., caseId format), but also does not mislead. Baseline 3 is appropriate.

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 'Get metadata for a specific case' and lists specific return fields (title, citation, decision date, keywords, URL). It distinguishes from siblings like list_cases and get_case_citations.

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 this tool is for retrieving a single case's metadata, but does not explicitly state when to use it versus alternatives (e.g., list_cases for listing or get_case_citations for citations). No when-not or alternative guidance.

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

get_case_citationsGet Case CitationsA

Read-only

Inspect

Get citation information for a case: what it cites, what cites it, or what legislation it references. Note: the CanLII API currently only supports English for this endpoint; French requests will fall back to English.

ParametersJSON Schema

Name	Required	Description	Default
`caseId`	Yes	Case ID (e.g. "1999canlii1527")
`citationType`	Yes	Type of citation data to retrieve
`databaseId`	Yes	Database ID (e.g. "onca")
`language`	No	Response language (currently only 'en' is supported by the API)	en

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds behavioral context (language fallback behavior) that annotations do not cover. No contradiction.

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?

Two short, clear sentences. Every sentence adds value. No unnecessary words.

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 4-param tool with no output schema, the description covers purpose and a key behavioral note. Slight gap on response format, but adequate given simplicity.

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?

Schema description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond summarizing the enum values and noting language limit.

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 verb 'Get' and resource 'citation information for a case', and lists the three types of citations (what it cites, what cites it, legislation). This distinguishes it from sibling tools like get_case and get_legislation.

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?

It includes a critical usage note about language fallback, but does not explicitly contrast with sibling tools or provide when-to-use/alternatives.

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

get_legislationGet LegislationA

Read-only

Inspect

Get metadata for a specific piece of legislation including title, citation, dates, and repeal status.

ParametersJSON Schema

Name	Required	Description	Default
`databaseId`	Yes	Legislation database ID
`language`	No	Response language	en
`legislationId`	Yes	Legislation ID from list_legislation (e.g. "rso-1990-c-a1")

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true, so the description's mention of 'metadata' aligns but adds no additional behavioral traits (e.g., rate limits, auth needs). No contradiction, but no extra context beyond what annotations provide.

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 a single, well-structured sentence with no extraneous words. It is front-loaded with the core purpose and includes key details efficiently.

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?

Without an output schema, the description lists fields returned (title, citation, dates, repeal status) but does not explicitly state the return format (e.g., single object). It is mostly complete for a simple retrieval tool, but could be slightly more precise.

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, with all three parameters described. The description mentions 'legislationId' with an example, but does not add significant meaning beyond schema definitions. Baseline score of 3 is appropriate.

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 verb 'Get', the resource 'metadata for a specific piece of legislation', and lists included fields (title, citation, dates, repeal status). It effectively distinguishes from sibling tools like list_legislation (listing) and get_case (different resource).

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 does not explicitly state when to use this tool versus alternatives like list_legislation. Usage is implied (for a single legislation vs. listing), but no direct guidance on when not to use or prerequisites are provided.

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

list_case_databasesList Case DatabasesA

Read-only

Inspect

List all courts and tribunals in the CanLII collection with their database IDs.

ParametersJSON Schema

Name	Required	Description	Default
`language`	No	Response language	en

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the descriptive burden is lower. The description adds that it lists all items, which implies a full list without filtering. However, it does not disclose whether the list is paginated, sorted, or if there are any limits. A score of 3 is appropriate given the safety annotations.

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 a single sentence with no redundant words. It conveys the essential information efficiently.

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 list tool with no output schema and one parameter, the description covers the main purpose. It could mention that the output is a list of database IDs and names, but that might be inferred. No critical gaps.

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?

There is only one parameter (language) with full schema coverage (100%). The description does not add any extra meaning beyond the schema's description and enum values. Baseline score of 3 is correct.

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 lists all courts and tribunals with their database IDs, which is a specific verb-resource combination. It distinguishes from siblings like list_cases and list_legislation_databases by focusing on court/tribunal databases.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. For example, it does not mention that this is a metadata listing tool, not for searching or retrieving case content. The agent has to infer from the name.

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

list_casesList CasesA

Read-only

Inspect

List decisions from a specific caselaw database. Returns case titles, citations, and IDs.

ParametersJSON Schema

Name	Required	Description	Default
`databaseId`	Yes	Database ID from list_case_databases (e.g. "onca", "csc-scc")
`decisionDateAfter`	No	Filter: decision date after (YYYY-MM-DD)
`decisionDateBefore`	No	Filter: decision date before (YYYY-MM-DD)
`language`	No	Response language	en
`offset`	No	Starting record index
`publishedAfter`	No	Filter: published on CanLII after this date (YYYY-MM-DD)
`publishedBefore`	No	Filter: published on CanLII before this date (YYYY-MM-DD)
`resultCount`	No	Number of results to return (max 10000)

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so agent knows it's safe. The description adds that it returns case titles, citations, and IDs. However, it does not disclose pagination behavior, default results, or date filtering specifics, which would be helpful beyond the schema.

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 very concise (two sentences) and front-loaded with the action. It is efficient but could be better structured (e.g., listing parameters or example).

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 no output schema, the description adequately states return values. However, it omits defaults (e.g., resultCount defaults to 25) and pagination details. For a list tool with 8 parameters, it is mostly complete.

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?

Schema description coverage is 100%, so parameters are well-documented structurally. The description adds no additional semantic meaning beyond what the schema provides, earning 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 it lists decisions from a specific caselaw database and explicitly mentions the returned fields (titles, citations, IDs). It distinguishes from siblings like get_case (single case) and list_case_databases (lists databases).

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 use with a specific databaseId but does not explicitly state when to use this tool versus alternatives like get_case or provide any exclusions or context for choosing this tool.

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

list_legislationList LegislationA

Read-only

Inspect

List statutes or regulations from a specific legislation database.

ParametersJSON Schema

Name	Required	Description	Default
`databaseId`	Yes	Legislation database ID from list_legislation_databases (e.g. "ons" for Ontario statutes)
`language`	No	Response language	en

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true, confirming read-only nature. The description adds no extra behavioral context, such as pagination or sorting, but does not contradict annotations.

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?

A single, front-loaded sentence efficiently conveys the core purpose. However, it could include brief usage guidance without becoming verbose.

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?

Given the simplicity (2 params, no output schema), the description is minimally adequate but lacks details on return format or content of the list, requiring the agent to infer.

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?

Schema coverage is 100%, with both parameters described in the schema. The description adds no additional meaning beyond what is in the schema, so baseline score of 3 applies.

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 it lists statutes or regulations from a specific database, using a specific verb and resource. It distinguishes from sibling tools like get_legislation (single item) and list_legislation_databases (databases list).

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 usage when listing from a specific database, but does not explicitly provide when to use or not, nor references alternative sibling tools. Context is inferred from names but not stated.

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

list_legislation_databasesList Legislation DatabasesB

Read-only

Inspect

List all legislation and regulation databases in the CanLII collection.

ParametersJSON Schema

Name	Required	Description	Default
`language`	No	Response language	en

TDQS

B3.4/5.0

Behavior4/5

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

The description aligns with the readOnlyHint annotation, indicating a safe read operation. No additional behavioral traits are disclosed, but since the annotation already covers it, the description is adequate.

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 a single sentence with no wasted words. It is concise, though it could benefit from more detail about the output or usage context.

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?

For a simple list tool with no output schema, the description does not explain what the response contains (e.g., names, IDs). It is minimally complete but could be improved.

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 for the single parameter, so the description adds no extra semantic value. Baseline 3 is appropriate.

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 it lists all legislation and regulation databases, using a specific verb and resource. However, it does not differentiate from the sibling tool 'list_legislation', which might also list legislation-related items, though likely documents rather than databases.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like list_case_databases or list_legislation. The description does not mention any context or exclusions.

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.

7 tool updatesv1.0.3Apr 25, 2026
- First observedget_case
- First observedget_case_citations
- First observedget_legislation
- First observedlist_case_databases
- First observedlist_cases
- First observedlist_legislation
- First observedlist_legislation_databases

Install Server

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

TDQS

A3.8/5.0

Disambiguation5/5

Each tool targets a distinct operation: retrieving specific case metadata, case citations, legislation, or listing various databases and documents. No functional overlap exists.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, e.g., get_case, list_cases, get_legislation, making the API predictable.

Tool Count4/5

7 tools is well-scoped for a legal database API, covering core retrieval and listing operations. Slightly on the smaller side but still appropriate.

Completeness3/5

The set covers basic CRUD-like read operations for cases and legislation, but lacks search/full-text query capabilities, which are common in legal research APIs.

Resources

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

Lawstronaut A
com.lawstronaut
Connect AI to millions of laws and court cases with the Lawstronaut MCP.
Legal & Compliance Research & Data Web Scraping
1631
mcp-agentcore A
com.geiant
AI governance MCP server for EU AI Act compliance and jurisdiction verification
Legal & Compliance AI & Machine Learning Government Data
32
Artificial Wit AI
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
Zapier
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297

Related MCP Servers

Legal Court MCP Server
Legal & Compliance Government Data Search
AiAgentKarl
A
license
A
quality
D
maintenance
MCP Server providing AI agents access to over 3 million US court decisions via CourtListener and EU legislation via EUR-Lex, with tools for searching cases, citations, judges, and court information.
Updated 5 months ago (2026-04-03 16:05 UTC)
6
MIT
courtlistener-mcp
Legal & Compliance Search RAG Systems
DefendTheDisabled
A
license
Not graded
quality
C
maintenance
An MCP server providing AI agents access to CourtListener's comprehensive legal database, featuring semantic search, hybrid search, citation verification, and research tools.
Updated 6 months ago (2026-03-07 19:01 UTC)
7
MIT
mcp-canada
Government Data Open Data
ReyemTech
A
license
A
quality
B
maintenance
MCP server giving AI agents structured access to Canadian federal, provincial, and municipal government data.
Updated 12 days ago (2026-08-24 15:57 UTC)
5
59
MIT
LegalMCP
Legal & Compliance Search Government Data
Mahender22
A
license
A
quality
B
maintenance
LegalMCP is a comprehensive US legal MCP server that enables AI assistants to search over 4 million US court opinions, manage Clio practice data, and access PACER federal filings through natural language.
Updated 3 months ago (2026-06-19 04:47 UTC)
18
65
MIT

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/Vaquill-AI/canlii-mcp'

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