Pakistan Case Law

by com.pakistancaselaw

Overview Discussions Admin

Server Details

Search 230,000+ Pakistani court judgments by keyword, citation, or the legal question they settle.

Ownership verified

Status: Healthy
Uptime: 100.0% over 46 days
Last Tested: 2026-10-21 01:23
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored 2026-10-17 19:30 across 7 tools

Disambiguation5/5

Each tool targets a clearly distinct operation: retrieval by id, exact citation lookup, full-text search, question-based search, forward/backward citation traversal, and most-cited ranking. The descriptions explicitly clarify boundaries, such as when to use search versus lookup_citation versus search_questions.

Naming Consistency4/5

All names use the caselaw_ prefix and snake_case, producing a largely predictable pattern. Minor deviations exist: caselaw_most_cited is adjective-based rather than verb_noun, and caselaw_get_cited_by includes a preposition, but overall consistency is strong.

Tool Count5/5

Seven tools is well-scoped for a case-law research server. Each tool serves a distinct research function, and there is no redundancy or bloat.

Completeness5/5

The surface covers discovery (search, question search, most cited), retrieval (get_case with summary/full-text modes), exact citation lookup, and full forward/backward citation graph traversal. No obvious gap exists for the stated case-law research domain.

Available Tools

7 tools

caselaw_get_caseA

Read-onlyIdempotent

Inspect

Fetch one judgment by id.

section='summary' (default) returns metadata + the headnote (plain-language summary, the
laws/provisions referred, and keyword tags) — read this first to judge relevance cheaply.
section='full' additionally returns the judgment body text (capped at ~40,000 chars; the
response flags body_truncated/body_chars_total when longer).

ParametersJSON Schema

Name	Required	Description	Default
`case_id`	Yes	Numeric judgment id (from a search/lookup/graph result)
`section`	No	'summary' = metadata + headnote (cheap); 'full' = + judgment text	summary
`response_format`	No		markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is carried. The description adds genuinely new behavior: the ~40,000-char body cap and the body_truncated/body_chars_total flags, plus what each section actually returns (headnote = laws/provisions + keyword tags). No auth or rate-limit context.

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 leading sentence states the core action, then the two section modes are explained in parallel order and the truncation caveat is attached where it is relevant. No filler sentences.

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?

An output schema exists, so return-value enumeration is not required, and the truncation signals are disclosed anyway. The only gap is the undocumented response_format parameter, which leaves the agent guessing at the markdown/json switch.

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?

Schema coverage is only 67%, but the description compensates by expanding on section semantics ('metadata + headnote … laws/provisions referred, and keyword tags') well beyond the terse enum description, and clarifies case_id is a judgment id. response_format is never explained in either the schema or the description.

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?

States a specific verb and resource with an explicit identifier scope: 'Fetch one judgment by id.' This clearly separates it from the search/lookup siblings, though it never names an alternative explicitly, so sibling differentiation is only implicit.

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 gives useful intra-tool guidance ('read this first to judge relevance cheaply') that steers the agent toward section='summary' before 'full'. It offers no cross-tool routing, however — nothing says how case_id is obtained or when this tool beats caselaw_search or caselaw_lookup_citation.

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

caselaw_get_citationsA

Read-onlyIdempotent

Inspect

Walk the citation graph FORWARD: list the in-corpus cases that THIS judgment cites (the precedents it relied on). Combine with caselaw_get_cited_by to traverse precedent backward and forward until a research question is resolved.

Most useful on RECENT judgments: a 2024-25 case usually has nobody citing it yet, but its
own citation list is a curated map of the established authority on the point.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`case_id`	Yes	Numeric judgment id
`response_format`	No		markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover readOnlyHint, idempotentHint, openWorldHint=false, so safety is handled. The description adds genuinely new behavioral context: results are restricted to in-corpus cases, and it explains why the tool's value differs by judgment age. It stops short of describing pagination behavior, though limit/offset are visible in 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, direction stated first, alternative second, usage heuristic last. No filler and nothing redundant with structured fields.

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?

With an output schema present, return values need no explanation, and the description covers scope, direction, and traversal strategy well. The one gap is that the pagination and format parameters are left entirely undocumented for a tool that can return many citations.

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

Parameters2/5

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

Schema description coverage is only 25% (only case_id documented as 'Numeric judgment id'), so the description is expected to compensate and does not. limit, offset, and response_format carry no explanation anywhere, and the description does not clarify what case_id accepts beyond the schema's own hint.

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+resource ('list the in-corpus cases that THIS judgment cites') and immediately disambiguates direction ('FORWARD'), naming the sibling caselaw_get_cited_by that goes the other way. An agent can distinguish it from the backward-traversal tool without opening any schema.

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 says when to combine it with caselaw_get_cited_by ('traverse precedent backward and forward until a research question is resolved') and gives a concrete scenario where it beats the alternative ('most useful on RECENT judgments... nobody citing it yet'). That is real when/when-not guidance.

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

caselaw_get_cited_byA

Read-onlyIdempotent

Inspect

Walk the citation graph BACKWARD: list later cases that cite THIS judgment (how it was subsequently treated — followed, distinguished, relied upon). Returns newest first.

Most useful on OLDER or landmark judgments: it shows whether the case is still followed and
where the principle has been applied since. A leading case can have hundreds of citing cases.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`case_id`	Yes	Numeric judgment id
`response_format`	No		markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare this a safe, idempotent, non-destructive read, so the safety profile is covered. The description adds genuinely non-structured context: result ordering (newest first) and scale expectations ('A leading case can have hundreds of citing cases'), which warns the agent to paginate. It does not mention auth or rate limits, but none are implied.

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-loaded with the core operation and direction, then use-case context. Three short paragraphs with no filler, though the second paragraph slightly restates the first's implication that citing cases reflect subsequent treatment.

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?

An output schema exists, so return formatting is not the description's burden. The description covers direction, ordering, semantics, and use case well; the only real gap is pagination/parameter behavior, which matters given the warning about hundreds of citing cases.

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

Parameters2/5

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

Schema description coverage is only 25% (only case_id is documented), and the description adds no parameter guidance at all — nothing about what limit/offset do, that limit caps at 50, or that response_format toggles output. With a low-coverage schema, the description is expected to compensate and does not.

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 (list later cases that cite this judgment) and pins down directionality — 'Walk the citation graph BACKWARD' — which implicitly separates it from the forward-looking sibling caselaw_get_citations. It also names the semantic payload (followed, distinguished, relied upon) so the agent knows what the results mean.

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?

Gives clear guidance on when this is valuable: 'Most useful on OLDER or landmark judgments' and explains why (shows whether the case is still followed). It stops short of explicitly naming the alternative tool and the condition that selects it, so the agent must infer the backward-vs-forward split from the sibling names.

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

caselaw_lookup_citationA

Read-onlyIdempotent

Inspect

Find the judgment(s) at an exact law-report citation.

Example: journal='PLD', year=1995, page=34  → PLD 1995 Supreme Court 34.
Omit page to list everything reported in that journal+year. Returns the same case shape
as caselaw_search.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No	Page/serial number in the report (optional)
`year`	No	Year of the report, e.g. 1995
`limit`	No
`offset`	No
`journal`	Yes	Law-report code, e.g. 'PLD', 'SCMR', 'CLC' (a whole citation such as 'PLD 1995 SC 34' is also understood)
`response_format`	No		markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description usefully adds the page-omission broadening behavior and that results match caselaw_search's case shape, but says nothing about what happens on a no-match (empty result vs. error) or about the default 20 / max 50 page limiting.

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?

Three short sentences, front-loaded with the purpose, followed by a worked example and the optional-parameter behavior. No sentence is redundant and nothing could be trimmed without losing information.

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?

With an output schema present, the description needn't explain return values, and it correctly limits itself to input semantics and the two lookup modes. The remaining gap is failure/pagination behavior (empty results, limit/offset) for a tool where a citation may simply not exist.

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?

Schema coverage is only 50%, but the description compensates by illustrating the citation semantics with a concrete mapping ('journal=PLD, year=1995, page=34 → PLD 1995 Supreme Court 34' and the omit-page variant), which is the core interpretive burden. The pagination and response_format parameters remain unexplained, though they are near-self-describing.

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?

States a specific verb and resource — 'Find the judgment(s) at an exact law-report citation' — and conveys the defining constraint (exact citation, as opposed to a free-text search). It references caselaw_search only for output shape, so the functional distinction from that sibling is implied rather than spelled out.

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 phrase 'exact law-report citation' clearly frames the situation this tool serves, and 'Omit page to list everything reported in that journal+year' documents a second usage mode. However, it never states explicitly when to prefer this over caselaw_search or caselaw_get_citations, and gives no exclusion guidance.

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

caselaw_most_citedA

Read-onlyIdempotent

Inspect

List the most-cited (landmark) judgments in the corpus, ranked by how many other cases cite them. A good entry point for the leading authorities on Pakistani law.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`offset`	No
`response_format`	No	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds that ordering is by incoming citation count, but says nothing about pagination behavior despite limit/offset params, so it adds only modest value beyond structured fields.

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 compact sentences with the ranking semantics front-loaded and the use-case hint following. No filler or repetition of the tool name.

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?

An output schema exists, so return values need no explanation, and the ranking rule is stated. However, the description leaves 'the corpus' undefined and omits any pagination note for a limit/offset list tool, which an agent would need to page results correctly.

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 0%, but all three parameters (limit with max 50, offset, response_format enum) are self-evident numeric/format controls with defaults, so the description need not compensate heavily. It still gives no syntax or pagination guidance, so it does not improve on the bare schema.

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?

States a specific verb and resource ('List the most-cited judgments') and defines the ordering rationale ('ranked by how many other cases cite them'), which sharply separates it from citation-traversal siblings like caselaw_get_cited_by. It doesn't name an alternative sibling explicitly, but the ranking definition makes the distinction inferable.

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?

"A good entry point for the leading authorities" implies a use case (starting research / discovering landmark cases) but gives no when-not guidance or explicit alternatives such as caselaw_search for topical lookup. Usage is implied rather than specified.

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

caselaw_searchA

Read-onlyIdempotent

Inspect

Full-text search of Pakistani judgments (Supreme Court, High Courts, Federal Shariat Court and tribunals, 1970 onward), with optional filters by court, judge, author, law report and year.

Ranking follows how lawyers research: nearness to the legal point decides which cases are
returned; among comparably-near cases, more senior court > larger bench > more recent >
more cited. For the current state of the law, add year_from (e.g. 2025); use sort='court'
for the most authoritative first.

With no query, the filters list judgments newest first - e.g. court='Supreme Court' gives the
latest Supreme Court judgments, journal='PLD' with year_from=year_to=2024 gives that volume,
and sort='recently_added' alone shows what was added to the site most recently.

Returns cases with id, title, citation, court, year, outcome, author (the judge who wrote it, when
known) and the public URL. For an exact
report citation use caselaw_lookup_citation. To read a case, pass its id to caselaw_get_case.

ParametersJSON Schema

Name	Required	Description	Default
`sort`	No	relevance (default: nearest on the point, then court/bench/recency/citations) \| newest (the ~200 closest matches in strict date order) \| court (most senior court first) \| recently_added (newest additions to the site). For the CURRENT law on a point, keep relevance and set year_from (e.g. 2025): strict date order can surface judgments that only mention the point in passing.	relevance
`court`	No	Only this court: 'Supreme Court', 'Lahore High Court' (or 'LHC'), 'Sindh High Court', 'Peshawar High Court', 'Islamabad High Court', 'Balochistan High Court', 'Federal Shariat Court', or a tribunal's name
`judge`	No	Only judgments where this judge sat on the bench. Spelling-tolerant: 'Asif Khosa', 'Qazi Faez Isa'. The reply names the judge it matched.
`limit`	No
`query`	No	Keywords, e.g. 'bail murder 302' or 'khula dower'. May be left out when a filter is given.
`author`	No	Only judgments this judge WROTE (the author of the judgment, who also sat on its bench) - narrower than `judge`, which includes every case the judge sat on. Spelling-tolerant like `judge`.
`offset`	No
`journal`	No	Only judgments reported in this law report: 'PLD', 'SCMR', 'CLC', 'YLR', 'PLC(CS)', 'PTD' ... With year_from/year_to it selects that volume, e.g. SCMR 2025.
`year_to`	No	Latest year (inclusive)
`year_from`	No	Earliest year (inclusive)
`response_format`	No		markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world search. Description goes beyond by explaining the ranking algorithm, pagination implications (limit max 50, offset exists), return fields (id, title, citation, court, year, outcome, author, URL), and filter-only behavior. Slight redundancy with the schema's sort description, but adds ranking rationale not fully in 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?

Front-loads scope and ranking, then examples, then returns and sibling routing. Mostly efficient, though the ranking paragraph and examples are slightly verbose. Every sentence earns its place, but could be tightened.

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 an 11-param search tool with an output schema, the description provides enough: scope, ranking, filter-only behavior, return fields (though output schema exists), and sibling routing. Missing explicit mention of pagination limits (limit max 50) and response_format, which are minor given the schema.

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?

Schema coverage is 73%, and the description adds meaningful semantics: distinguishes judge vs author (narrower, wrote vs sat), explains ranking effect of sort, year_from for current law, and journal+year_from/year_to for volumes. Covers most parameters but not limit/offset/response_format behavior.

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 (Full-text search) and resource (Pakistani judgments) with clear scope (courts, 1970 onward). Distinguishes from siblings explicitly by naming caselaw_lookup_citation for exact citations and caselaw_get_case for reading a case.

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?

Offers concrete when-to-use guidance: add year_from for current law, use sort='court' for authoritative, no-query filter-only listing, journal+year range for a volume. Names alternatives for other tasks (exact citation, read case by id).

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

caselaw_search_questionsA

Read-onlyIdempotent

Inspect

Find judgments by the QUESTION they settle, rather than by words they contain.

Every judgment summary on this corpus records the questions that judgment actually decides — e.g.
"Does delay in lodging the FIR by itself entitle the accused to bail?" This searches those
questions, so it matches the shape a legal problem arrives in rather than the vocabulary a
1987 bench happened to use.

COVERAGE IS PARTIAL: only some judgments have a summary with questions yet (the response's
`coverage_note` gives the current live ratio, which keeps growing). An empty result means no
*summarised* judgment matched — it does NOT mean no such judgment exists. Fall back to
caselaw_search, which covers the whole corpus.

The questions are prepared from the judgment text. They are a finding aid, not a
holding: cite the judgment, never the question. Pass an id to caselaw_get_case to read it.

ParametersJSON Schema

Name	Required	Description	Default
`court`	No	Only this court, e.g. 'Supreme Court' or 'Lahore High Court'
`judge`	No	Only judgments where this judge sat on the bench (spelling-tolerant, e.g. 'Mansoor Ali Shah')
`limit`	No
`query`	Yes	The legal question or its subject, in the words a judgment would use — 'delay in lodging FIR', 'concurrent findings of fact', 'pre-arrest bail murder'
`offset`	No
`year_to`	No	Latest year (inclusive)
`year_from`	No	Earliest year (inclusive)
`response_format`	No		markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavioral context: coverage is partial, an empty result means 'no summarised judgment matched' rather than 'no such judgment exists', and the questions are a finding aid that must not be cited as a holding.

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-loaded with the core distinction, and the partial-coverage caveat is emphasised in caps where it matters most. The 'shape a legal problem arrives in rather than the vocabulary a 1987 bench happened to use' line is evocative but slightly more prose than an agent needs.

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?

With an output schema present, the description correctly avoids explaining return values while covering the things an agent cannot infer: the partial-coverage caveat, the meaning of an empty result, the fallback path, and the citation caveat on returned questions.

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 63%, so the schema documents most filters (court, judge, years, query examples) on its own. The description adds conceptual meaning to what the query targets but says nothing about the court/judge/year/limit/offset filters, leaving the remaining gap unfilled.

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 and unusual verb+resource: searching judgments by the questions they decide, not by their words. It explicitly contrasts with the sibling caselaw_search ('Fall back to caselaw_search, which covers the whole corpus'), so an agent can distinguish the two without opening either schema.

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?

Gives explicit when-to-use (a legal problem arriving as a question) and when-not/alternative (empty results do not imply absence; fall back to caselaw_search). It also routes forward to caselaw_get_case for reading a matched judgment id.

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.

1 tool updateOct 17, 2026

Changedcaselaw_search1 field changed

addedInput schema / properties / author

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 100,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only judgments this judge WROTE (the author of the judgment, who also sat on its bench) - narrower than `judge`, which includes every case the judge sat on. Spelling-tolerant like `judge`.",
+  "title": "Author"
+}

1 tool updateOct 15, 2026

Changedcaselaw_lookup_citation10 fields changed

changedInput schema / properties / journal / description

Previous value: -"Law-report code, e.g. 'PLD', 'SCMR', 'CLC'"New value: +"Law-report code, e.g. 'PLD', 'SCMR', 'CLC' (a whole citation such as 'PLD 1995 SC 34' is also understood)"

changedInput schema / properties / journal / maxLength
```
Previous value: -30New value: +120
```

changedInput schema / properties / page / anyOf

Previous value: -[
-  {
-    "minimum": 1,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / year / anyOf

Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / year / default
```
Added value: +null
```
addedInput schema / properties / year / description
```
Added value: +"Year of the report, e.g. 1995"
```
removedInput schema / properties / year / maximum
```
Removed value: -2100
```
removedInput schema / properties / year / minimum
```
Removed value: -1900
```
removedInput schema / properties / year / type
```
Removed value: -"integer"
```

changedInput schema / required

Previous value: -[
-  "journal",
-  "year"
-]New value: +[
+  "journal"
+]

7 tool updatesOct 1, 2026
- Changedcaselaw_get_case9 fields changed
  - removedInput schema / $defs
```
Removed value: -{
-  "Fmt": {
-    "enum": [
-      "markdown",
-      "json"
-    ],
-    "title": "Fmt",
-    "type": "string"
-  },
-  "Section": {
-    "enum": [
-      "summary",
-      "full"
-    ],
-    "title": "Section",
-    "type": "string"
-  }
-}
```
  - removedInput schema / properties / response_format / $ref
```
Removed value: -"#/$defs/Fmt"
```
  - addedInput schema / properties / response_format / enum
```
Added value: +[
+  "markdown",
+  "json"
+]
```
  - addedInput schema / properties / response_format / title
```
Added value: +"Response Format"
```
  - addedInput schema / properties / response_format / type
```
Added value: +"string"
```
  - removedInput schema / properties / section / $ref
```
Removed value: -"#/$defs/Section"
```
  - addedInput schema / properties / section / enum
```
Added value: +[
+  "summary",
+  "full"
+]
```
  - addedInput schema / properties / section / title
```
Added value: +"Section"
```
  - addedInput schema / properties / section / type
```
Added value: +"string"
```
- Changedcaselaw_get_citations5 fields changed
  - removedInput schema / $defs
```
Removed value: -{
-  "Fmt": {
-    "enum": [
-      "markdown",
-      "json"
-    ],
-    "title": "Fmt",
-    "type": "string"
-  }
-}
```
  - removedInput schema / properties / response_format / $ref
```
Removed value: -"#/$defs/Fmt"
```
  - addedInput schema / properties / response_format / enum
```
Added value: +[
+  "markdown",
+  "json"
+]
```
  - addedInput schema / properties / response_format / title
```
Added value: +"Response Format"
```
  - addedInput schema / properties / response_format / type
```
Added value: +"string"
```
- Changedcaselaw_get_cited_by5 fields changed
  - removedInput schema / $defs
```
Removed value: -{
-  "Fmt": {
-    "enum": [
-      "markdown",
-      "json"
-    ],
-    "title": "Fmt",
-    "type": "string"
-  }
-}
```
  - removedInput schema / properties / response_format / $ref
```
Removed value: -"#/$defs/Fmt"
```
  - addedInput schema / properties / response_format / enum
```
Added value: +[
+  "markdown",
+  "json"
+]
```
  - addedInput schema / properties / response_format / title
```
Added value: +"Response Format"
```
  - addedInput schema / properties / response_format / type
```
Added value: +"string"
```
- Changedcaselaw_lookup_citation5 fields changed
  - removedInput schema / $defs
```
Removed value: -{
-  "Fmt": {
-    "enum": [
-      "markdown",
-      "json"
-    ],
-    "title": "Fmt",
-    "type": "string"
-  }
-}
```
  - removedInput schema / properties / response_format / $ref
```
Removed value: -"#/$defs/Fmt"
```
  - addedInput schema / properties / response_format / enum
```
Added value: +[
+  "markdown",
+  "json"
+]
```
  - addedInput schema / properties / response_format / title
```
Added value: +"Response Format"
```
  - addedInput schema / properties / response_format / type
```
Added value: +"string"
```
- Changedcaselaw_most_cited5 fields changed
  - removedInput schema / $defs
```
Removed value: -{
-  "Fmt": {
-    "enum": [
-      "markdown",
-      "json"
-    ],
-    "title": "Fmt",
-    "type": "string"
-  }
-}
```
  - removedInput schema / properties / response_format / $ref
```
Removed value: -"#/$defs/Fmt"
```
  - addedInput schema / properties / response_format / enum
```
Added value: +[
+  "markdown",
+  "json"
+]
```
  - addedInput schema / properties / response_format / title
```
Added value: +"Response Format"
```
  - addedInput schema / properties / response_format / type
```
Added value: +"string"
```
- Changedcaselaw_search5 fields changed
  - removedInput schema / $defs
```
Removed value: -{
-  "Fmt": {
-    "enum": [
-      "markdown",
-      "json"
-    ],
-    "title": "Fmt",
-    "type": "string"
-  }
-}
```
  - removedInput schema / properties / response_format / $ref
```
Removed value: -"#/$defs/Fmt"
```
  - addedInput schema / properties / response_format / enum
```
Added value: +[
+  "markdown",
+  "json"
+]
```
  - addedInput schema / properties / response_format / title
```
Added value: +"Response Format"
```
  - addedInput schema / properties / response_format / type
```
Added value: +"string"
```
- Changedcaselaw_search_questions5 fields changed
  - removedInput schema / $defs
```
Removed value: -{
-  "Fmt": {
-    "enum": [
-      "markdown",
-      "json"
-    ],
-    "title": "Fmt",
-    "type": "string"
-  }
-}
```
  - removedInput schema / properties / response_format / $ref
```
Removed value: -"#/$defs/Fmt"
```
  - addedInput schema / properties / response_format / enum
```
Added value: +[
+  "markdown",
+  "json"
+]
```
  - addedInput schema / properties / response_format / title
```
Added value: +"Response Format"
```
  - addedInput schema / properties / response_format / type
```
Added value: +"string"
```

1 tool updateSep 30, 2026

Changedcaselaw_search_questions1 field changed

addedInput schema / properties / judge

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 100,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only judgments where this judge sat on the bench (spelling-tolerant, e.g. 'Mansoor Ali Shah')",
+  "title": "Judge"
+}

2 tool updatesSep 30, 2026

Changedcaselaw_search13 fields changed

addedInput schema / properties / court

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 100,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only this court: 'Supreme Court', 'Lahore High Court' (or 'LHC'), 'Sindh High Court', 'Peshawar High Court', 'Islamabad High Court', 'Balochistan High Court', 'Federal Shariat Court', or a tribunal's name",
+  "title": "Court"
+}

addedInput schema / properties / journal

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 20,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only judgments reported in this law report: 'PLD', 'SCMR', 'CLC', 'YLR', 'PLC(CS)', 'PTD' ... With year_from/year_to it selects that volume, e.g. SCMR 2025.",
+  "title": "Journal"
+}

addedInput schema / properties / judge

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 100,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only judgments where this judge sat on the bench. Spelling-tolerant: 'Asif Khosa', 'Qazi Faez Isa'. The reply names the judge it matched.",
+  "title": "Judge"
+}

addedInput schema / properties / query / anyOf

Added value: +[
+  {
+    "maxLength": 200,
+    "minLength": 2,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / query / default
```
Added value: +null
```

changedInput schema / properties / query / description

Previous value: -"Keywords, e.g. 'bail murder 302' or 'khula dower'"New value: +"Keywords, e.g. 'bail murder 302' or 'khula dower'. May be left out when a filter is given."

removedInput schema / properties / query / maxLength
```
Removed value: -200
```
removedInput schema / properties / query / minLength
```
Removed value: -2
```
removedInput schema / properties / query / type
```
Removed value: -"string"
```

changedInput schema / properties / sort / description

Previous value: -"relevance (default: nearest on the point, then court/bench/recency/citations) | newest (latest law first — useful because amendments supersede) | court (most senior court first)"New value: +"relevance (default: nearest on the point, then court/bench/recency/citations) | newest (the ~200 closest matches in strict date order) | court (most senior court first) | recently_added (newest additions to the site). For the CURRENT law on a point, keep relevance and set year_from (e.g. 2025): strict date order can surface judgments that only mention the point in passing."

addedInput schema / properties / year_from

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 2100,
+      "minimum": 1900,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Earliest year (inclusive)",
+  "title": "Year From"
+}

addedInput schema / properties / year_to

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 2100,
+      "minimum": 1900,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Latest year (inclusive)",
+  "title": "Year To"
+}

removedInput schema / required
```
Removed value: -[
-  "query"
-]
```

Changedcaselaw_search_questions3 fields changed

addedInput schema / properties / court

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 100,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only this court, e.g. 'Supreme Court' or 'Lahore High Court'",
+  "title": "Court"
+}

addedInput schema / properties / year_from

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 2100,
+      "minimum": 1900,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Earliest year (inclusive)",
+  "title": "Year From"
+}

addedInput schema / properties / year_to

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 2100,
+      "minimum": 1900,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Latest year (inclusive)",
+  "title": "Year To"
+}

1 tool updateSep 30, 2026

Changedcaselaw_get_case1 field changed

changedInput schema / properties / section / description

Previous value: -"'summary' = metadata + AI headnote (cheap); 'full' = + judgment text"New value: +"'summary' = metadata + headnote (cheap); 'full' = + judgment text"

7 tool updatesSep 6, 2026
- First observedcaselaw_get_case
- First observedcaselaw_get_citations
- First observedcaselaw_get_cited_by
- First observedcaselaw_lookup_citation
- First observedcaselaw_most_cited
- First observedcaselaw_search
- First observedcaselaw_search_questions

Publisher details

Operator: Pakistan Case Law · Publisher source
Operator website: https://pakistancaselaw.com/ · Publisher source
Vendor relationship: First-party · Publisher source
Documentation: https://pakistancaselaw.com/ · Publisher source
Trust center: https://pakistancaselaw.com/for-ai · Publisher source
Restrictions: Not applicable

Related MCP Connectors

FAI Legal Research A
site.failegal
Pakistani case law and statutes: Supreme Court and High Court judgments, laws, drafting templates.
Legal & Compliance Government Data
51
legal-data-hunter AOAuth
io.github.ZachLaik
Search 18M+ legal documents worldwide — case law, legislation, and doctrine across 110+ countries.
Legal & Compliance Government Data Search
2104
Malaysia CourtDBOAuth
io.github.IndoTender
Malaysian court judgment search for Federal Court, Court of Appeal, High Court cases and parties.
Legal & Compliance Government Data Search
1
NyayAssistOAuth
ai.nyayassist
Indian legal research, judgments and Acts, drafting, translation, matters and due diligence.
Legal & Compliance Research & Data Language Translation
1

Related MCP Servers

pk-eli-mcp
Government Data Legal & Compliance
matematicsolutions
A
license
A
quality
B
maintenance
MCP server for searching and retrieving Pakistani federal statutes and Supreme Court judgments with structured citations, using static HuggingFace datasets.
Updated 12 days ago (2026-10-08 14:58 UTC)
6
96 PyPI
Apache 2.0
scratchbrief-ind-mcp
Legal & Compliance Search Government Data
beral-lab
F
license
Not graded
quality
C
maintenance
Enables searching IndiaKanoon's live index of Indian case law, legislation, the Constitution, treaties, and parliamentary material, then retrieving full document text with pagination and excerpt targeting. Also traces precedent chains by listing the cases that cite, or are cited by, a given judgment.
Updated a month ago (2026-09-13 16:29 UTC)
-
uk-caselaw
Legal & Compliance Government Data Open Data
pipeworx-io
A
license
Not graded
quality
B
maintenance
Enables searching and retrieving full-text UK court judgments and tribunal decisions from The National Archives' Find Case Law service by subject, party, judge, or neutral citation.
Updated 24 days ago (2026-09-26 22:04 UTC)
12 npm
MIT
juris-pj-mcp
Legal & Compliance Government Data Search
pipaacebedo
A
license
A
quality
B
maintenance
Enables searching and reading Peru's National Systematized Jurisprudence from the Judiciary's public portal, including resolutions and arbitration award records, with full-text and exact-catalog filtering plus paginated results. Users can retrieve complete summaries, public PDF URLs, and complete Excel exports of a search without any authentication or browser.
Updated 4 days ago (2026-10-17 06:00 UTC)
10
1
Apache 2.0

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?