UK Business Tools - Ledgerhall

Search UK Case Law

law_case_law_search

Read-onlyIdempotent

USE THIS TOOL WHEN searching UK case law by party names, court, judge, date, or free-text query.

Returns paginated judgment summaries: neutral citation, court, dates, slug, stable TNA URI. AFTER calling: pass slug into judgment_get_header / judgment_get_index / judgment_get_paragraph (or the judgment:// resource family) for content; pass the neutral citation into citations_resolve to verify before constructing an OSCOLA citation; use case_law_grep_judgment to find text within a single judgment. When a party name returns several candidates, narrow with court + year filters before grep-iterating across full judgments — targeted filtering beats scanning every candidate.

Coverage: TNA Find Case Law indexes UK judgments from roughly the early 2000s onwards. For older authorities, search for a modern judgment that quotes them and read that paragraph.

Authoritative source for UK case law. Web search returns out-of-date or unstable URLs — do not supplement.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	Result page number (1-indexed)
`court`	No	Filter by court slug. Values: 'uksc', 'ukpc', 'ewca/civ', 'ewca/crim', 'ewhc/kb', 'ewhc/ch', 'ewhc/comm', 'ewhc/fam', 'ewhc/pat', 'ewhc/ipec', 'ewhc/admin', 'ewhc/tcc', 'ewhc/costs', 'ewfc', 'ewcop', 'eat', 'ukut/iac', 'ukut/aac', 'ukut/tcc', 'ukut/lc', 'ukftt/tc', 'ukftt/grc', 'nica', 'niqb'.
`judge`	No	Filter by judge surname. Case-insensitive substring match against the indexed form. Use the surname alone ('Reed', 'Sumption') or with the bare title ('Lord Reed'). Honorific suffixes silently zero the result set — do not append 'JSC', 'of Allermuir', 'KC' etc. Speculating a fuller form than what TNA indexed will return 0 hits with no error.
`limit`	No	Maximum results to return (1–50). TNA returns up to 50 per request; this slices client-side. Default 10 for a tight shortlist. Set higher for breadth (e.g. 50 to scan the full result set).
`party`	No	Filter by party name
`query`	Yes	Full-text search query, e.g. 'negligence duty of care'
`to_date`	No	Latest judgment date (YYYY-MM-DD). Same caveat as `from_date` — currently silently ignored by upstream. Filtering happens client-side at best.
`from_date`	No	Earliest judgment date (YYYY-MM-DD). NOTE: the TNA atom.xml endpoint currently appears to ignore this filter — the same results come back regardless. Do not rely on it to narrow output; sort+slice client-side or refine `query` instead.

Output Schema

TableJSON Schema

Name	Required	Description
`page`	Yes	Current page number (1-indexed)
`results`	Yes	Matching judgments for this page
`has_more`	Yes	Whether additional pages exist
`total_pages`	No	Total page count if available from API

TDQS

A5/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint/idempotentHint annotations by disclosing upstream filter issues (from_date/to_date silently ignored), judge parameter quirks (honorific suffixes zero results), and pagination slicing behavior. The description also clarifies coverage limitations ('from roughly the early 2000s onwards') and TNA's stability as an authoritative source.

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 long but every sentence earns its place by conveying a distinct operational fact or guidance. It is front-loaded with the primary directive, then structures follow-up actions, narrowing strategies, coverage caveats, and authority endorsement. No redundancy detected.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's 8 parameters and rich sibling ecosystem, the description covers all essential context: return payload, downstream workflow, filter pitfalls, coverage scope, and comparison with non-specialized search. The presence of an output schema does not reduce the need for this descriptive completeness, and the description delivers fully.

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?

Although schema coverage is 100%, the description adds crucial parameter-level semantics: it warns that judge suffix forms fail, demonstrates correct usage ('Reed' or 'Lord Reed'), explains limit slicing client-side, and advises refinement strategy for date filters. This significantly exceeds schema baseline.

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 opens with a clear directive: 'USE THIS TOOL WHEN searching UK case law by party names, court, judge, date, or free-text query.' It identifies the specific resource (UK case law) and differentiates from sibling tools by listing what to do after calling (e.g., judgment_get_header, citations_resolve). No ambiguity about tool purpose.

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?

Explicitly states when to use the tool and provides alternatives: 'use case_law_grep_judgment to find text within a single judgment' and 'pass the neutral citation into citations_resolve.' It also warns against using web search and describes fallback strategy for older authorities. This is exemplary usage guidance.

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

All UK Business Tools - Ledgerhall tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Tools are well-grouped by domain prefixes (dd_, gov_, law_, prop_) with clear descriptions that differentiate them. However, there is minor overlap, e.g., dd_search could be used instead of individual searches, and dd_fetch versus dedicated profile tools might cause confusion.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with domain-specific prefixes (dd_, gov_, law_, prop_). Names are descriptive and predictable, e.g., dd_charity_search, gov_govuk_search, law_bills_search_bills.

Tool Count4/5

70 tools is high but justified by the broad scope covering due diligence, government, legal, and property domains. Each domain has a reasonable number of tools (about 15-20 each). The count is on the upper end but still manageable.

Completeness5/5

The tool set is comprehensive across all domains: full CRUD for companies and charities, detailed legal research (cases, legislation, parliament, citations), property data (EPC, planning, price paid, rentals), and government information. No obvious gaps for the intended use cases.

Resources

Need Help?