CaseNode Case Law API

Search cases

search_cases

Read-only

Search UK case law — judgments and tribunal decisions.

Use this to find cases on a topic, by party name, or mentioning a legal concept.
Returns cases ranked by relevance with citation counts. Legislation and
procedural rules are not searchable (the corpus holds them as citation
targets with no text) — use resolve_citation for a named statute or rule.

Args:
    query: Natural language search (e.g. "tenant's right to manage", "unfair dismissal")
    domain: Legal domain slug (e.g. "landlord-tenant", "employment", "family")
    court: Court code (e.g. "UKSC", "EWCA-Civil", "EWHC-Ch", "FTT-Property")
    year_from: Earliest year to include
    year_to: Latest year to include
    respondent: Defending party — respondent / defendant name (e.g. "London Borough of Lambeth") — substring match
    claimant: Bringing party — applicant / claimant / appellant name — substring match
    disposition: Case outcome (allow, dismiss, grant, quash, refuse, remit)
    judgment_status: Status of judgment (approved, draft, handed down)
    appeal_from: Citation of the decision appealed from — substring match
    cited_by_min: Minimum citation count (only show influential cases)
    jurisdiction: "England & Wales", "Scotland", "United Kingdom"
    topic: Legal topic slugs — multi-select (e.g. ["unfair-dismissal", "discrimination"])
    mode: "hybrid" (default; best where the embedding model is enabled), "keyword", or "semantic". semantic/hybrid fall back to keyword when the model is unavailable — the response "mode" reports what ran.
    limit: Max results (default 20)

Input Schema

Name	Required	Default
`mode`	No	hybrid
`court`	No
`limit`	No
`query`	Yes
`topic`	No
`domain`	No
`year_to`	No
`claimant`	No
`year_from`	No
`respondent`	No
`appeal_from`	No
`disposition`	No
`cited_by_min`	No
`jurisdiction`	No
`judgment_status`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 28, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover read-only safety and closed-world scope. The description adds valuable behavioral context beyond them: results are ranked by relevance with citation counts, mode may fall back from semantic/hybrid to keyword, and the response 'mode' reports what actually ran. It doesn't cover pagination or rate limits, so not a 5.

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?

Front-loads purpose and the key corpus limitation before the args list. The args block is long but each entry earns its place given 15 parameters and zero schema descriptions; some entries could be compressed slightly but none are filler.

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 15-parameter search tool with no output schema, the description is nearly complete: it explains result ranking, citation counts, mode behavior, and the corpus limitation. Minor gaps such as pagination or exact result shape are acceptable since no output schema exists and the core return semantics are stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does: every one of the 15 parameters is documented with type, meaning, and examples, including substring-match behavior, multi-select topics, enum-like values for disposition/judgment_status/jurisdiction, and mode fallback semantics.

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?

States a specific verb and resource ('Search UK case law — judgments and tribunal decisions') and explicitly distinguishes the searchable corpus from legislation/procedural rules, naming the sibling resolve_citation for those. An agent can tell it apart from the other search/extract tools without opening schemas.

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

Usage Guidelines5/5

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

Says explicitly when to use it (topic, party name, legal concept) and when not to (legislation and procedural rules are not searchable). It names the alternative resolve_citation for statutes/rules, giving clear routing guidance.

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

All CaseNode Case Law API tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?