Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BAILII MCP Server Search BAILII for cases about HMO licensing"
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.
Search UK case law on BAILII. Retrieve judgments with automatic section extraction (summary, conclusions, discussion, background). Runs locally — BAILII blocks cloud IPs.
No install needed — uvx runs it directly from PyPI:
uvx bailii-mcppip install bailii-mcp
bailii-mcpRequires Python 3.10+.
Related MCP server: UK Case Law MCP Server
Add to your claude_desktop_config.json:
{
"mcpServers": {
"bailii": {
"command": "uvx",
"args": ["bailii-mcp"]
}
}
}claude mcp add bailii -- uvx bailii-mcpAdd to .vscode/settings.json or use the MCP panel:
{
"mcp": {
"servers": {
"bailii": {
"command": "uvx",
"args": ["bailii-mcp"]
}
}
}
}If you installed via pip install bailii-mcp, use "command": "bailii-mcp" and "args": [] instead.
git clone https://github.com/paulieb89/bailii-mcp.git
cd bailii-mcp
pip install -e .Once connected, just ask Claude naturally:
"Search BAILII for cases about HMO licensing"
"Find recent whistleblowing employment tribunal cases"
"Get the summary of Chinn v Hoilund-Carlsen"
"What did the court hold in that case?"
"Show me the discussion section"
Tool | What it does |
| Full-text search across all BAILII courts. Returns titles, citations, and links. |
| Retrieve judgment text. Defaults to summary + conclusions (~5000 chars). |
| List available UK courts (UKSC, EWCA, EWHC, UKUT, EAT, etc). |
Judgments are large (30-100KB). By default, only the summary and conclusions are returned. Ask for more if you need it:
Default: summary + conclusions (5000 chars)
Specific section: "show me the discussion" → pulls just that section
Full text: "get the complete judgment" → returns everything
Sections detected: summary, conclusions, held, discussion, background
BAILII blocks requests from cloud servers and datacenters. This server runs on your machine, so requests go through your residential IP.
For case law that doesn't need BAILII specifically, uk-legal-mcp provides case law via the National Archives API — hosted on Fly.io, no local setup needed.
This BAILII server is useful when you need:
Employment tribunal decisions (EAT coverage is stronger on BAILII)
Older cases not yet in the TNA database
Specific tribunals with better BAILII indexing
BAILII terms prohibit bulk downloading — use for targeted research only
Be reasonable with request rate
Section extraction depends on judgment formatting — not all judgments have clear section headers
Apache 2.0
Paul Boucherat — building MCP servers for UK property, legal, and project controls.
Retrieve a BAILII judgment, optionally filtered to a specific section.
Use the path returned by bailii_search. By default returns summary + conclusions (or first 5000 chars if no sections detected). Use section='all' for the complete text.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input containing: - path (str): BAILII document path - section (str, optional): 'summary', 'conclusions', 'held', 'discussion', 'background', 'all' - max_chars (int, optional): Maximum characters to return (default 5000) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. Description adds valuable context: default returns summary+conclusions or first 5000 chars, section='all' for full text, and max_chars limit. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second gives essential usage. No unnecessary words, front-loaded with key 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?
Given the presence of output schema, return values need not be explained. Tool prerequisites, default behavior, and all options are covered. Sufficient for correct invocation.
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 detailed descriptions. The main description adds pragmatic usage context (e.g., 'Obtain this from bailii_search') and clarifies default behavior, complementing the 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 the action ('Retrieve') and resource ('BAILII judgment'), with the option to filter by section. It distinguishes from siblings by specifying reliance on path from bailii_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?
Explicitly advises to 'Use the path returned by bailii_search', setting clear context for when to use. Could further clarify when not to use, but 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 the main UK courts and tribunals available on BAILII.
Returns court codes useful for constructing direct BAILII URLs or understanding search results.
Returns: str: JSON object mapping court codes to court names.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description adds non-critical context about the return format (JSON mapping codes to names). 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?
The description is extremely concise with three well-structured sentences. No wasted words; front-loaded with 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?
Given no parameters and the presence of an output schema, the description fully covers what the tool does and what it returns. No gaps.
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?
No parameters exist, so the baseline is 4. The description does not need to add 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 title and description clearly state the verb 'list' and resource 'courts'. It is distinct from sibling tools (bailii_get_judgment, bailii_search) which perform different actions.
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 explains the output is useful for constructing BAILII URLs or understanding search results, providing context for when to use it. It does not explicitly exclude scenarios but is sufficient for this simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search BAILII for UK case law by keyword or phrase.
Searches the full BAILII database including UKSC, EWCA, EWHC, House of Lords, tribunals, and Irish courts. Returns a list of matching cases with titles, citations, and document paths to use with bailii_get_judgment.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Search parameters containing: - query (str): Search terms - max_results (int): Number of results to return (default 10) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by disclosing the search scope (full BAILII database) and return format (list with titles, citations, paths), which complements the 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 two sentences: the first states the action, and the second provides scope, output, and relation to a sibling tool. No unnecessary words, well-structured for quick understanding.
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 presence of an output schema, the description adequately covers the search scope, output fields, and linkage to bailii_get_judgment. It is complete for a search tool of moderate complexity, though pagination or error states are not mentioned.
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 detailed parameter descriptions (query and max_results). The description only restates 'keyword or phrase' without adding new meaning, so it meets the baseline but does not exceed it.
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 BAILII for UK case law by keyword/phrase, specifies the scope (full database including specific courts) and output fields (titles, citations, paths), and distinguishes from siblings by mentioning the document paths can be used with bailii_get_judgment.
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 context on when to use (to find cases) and implies the use of a sibling tool (bailii_get_judgment) to get full text, but lacks explicit guidance on when not to use or alternatives like bailii_list_courts.
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.
v1.0.2bailii_get_judgmentbailii_list_courtsbailii_searchEach tool has a distinct purpose: searching case law, listing courts, and retrieving a judgment. No overlap or ambiguity.
All tools follow the consistent pattern 'bailii_verb_noun' (list_courts, search, get_judgment), making it predictable.
Three tools are well-scoped for a legal research server, covering search, court info, and judgment retrieval without unnecessary bulk.
The core workflow of searching and retrieving judgments is complete. However, advanced filtering by court or date is missing, which slightly limits coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search UK Acts, Statutory Instruments, and legislation with full text retrieval
Search U.S. case law, fetch opinions, and ask matter-aware legal questions over your documents.
Resolve, search and verify legal citations against the official sources, with provenance.
UK case law MCP (21 tools). Free API key: casenode.ai/api/signup → Dashboard → API keys.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/paulieb89/bailii-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
