Pakistan Case Law

caselaw_search

Read-onlyIdempotent

Full-text search of Pakistani judgments (Supreme Court, High Courts, Federal Shariat Court and tribunals, 1970 onward), with optional filters by court, judge, 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 and the public URL. For an exact
report citation use caselaw_lookup_citation. To read a case, pass its id to caselaw_get_case.

Input Schema

TableJSON 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.
`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

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedSep 30, 2026

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"
-]
```

First observedSep 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond them: it discloses the actual ranking algorithm (legal nearness, then court seniority, bench size, recency, citations), describes the no-query behavior branch (filters alone list judgments newest first), and lists the returned fields. This is behavior an agent could not derive from annotations or 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?

Three short paragraphs, front-loaded with purpose then ranking then no-query behavior, and each sentence carries usable information. Slight redundancy with the sort parameter's own schema description is the main cost, but nothing is fatuous.

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?

For a 10-parameter, zero-required search tool with an output schema, the description covers the ambiguity that matters: corpus scope, ranking, the empty-query mode, filter combination semantics, and hand-off to the sibling tools. An agent has everything needed to call it correctly on the first attempt.

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 70%, and the description adds real meaning on top: it explains what happens when query is omitted, how journal interacts with year_from/year_to to select a volume (e.g. SCMR 2025), and the trade-off between relevance and strict date order. It adds nothing for limit/offset, which are undocumented in both schema and description, so it stops short of full coverage.

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 ('Full-text search of Pakistani judgments') plus the exact corpus scope (Supreme Court, High Courts, Federal Shariat Court, tribunals, 1970 onward) and the filter dimensions. It also explicitly routes to two siblings (caselaw_lookup_citation for exact citations, caselaw_get_case to read a case), so an agent can distinguish it from the other six tools without opening a 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 concrete when-to-use rules: add year_from (e.g. 2025) for the current state of the law, use sort='court' for the most authoritative first, and drop the query entirely when only filters are needed. It also names the alternative tools and the condition that selects each, leaving nothing to inference.

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

All Pakistan Case Law 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?