A
licenseA
qualityA
maintenanceMCP server for searching and retrieving Pakistani federal statutes and Supreme Court judgments with structured citations, using static HuggingFace datasets.
6
47 PyPI
Apache 2.0
Pakistan Case Law
Server Details
Search 230,000+ Pakistani court judgments by keyword, citation, or the legal question they settle.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 25 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.1/5.0
Scored across 7 tools
Disambiguation5/5
Each tool has a clearly distinct role: full-text search, question-based search, exact citation lookup, case retrieval, forward citation traversal, backward citation traversal, and landmark ranking. The two citation-graph tools are explicitly distinguished as forward vs backward, and search vs search_questions is clarified with coverage caveats.
Naming Consistency4/5
All tools use the caselaw_ prefix and snake_case, with mostly predictable verb_noun or action-oriented names. The main minor deviation is caselaw_most_cited, which is more adjectival than the verb-based pattern used by the rest.
Tool Count5/5
Seven tools is well-scoped for a specialized case-law research server. Each tool earns its place by covering a distinct retrieval or citation-analysis need without excessive surface area.
Completeness4/5
The surface covers core legal research workflows: search, exact citation lookup, case retrieval, citation graph traversal, and landmark discovery. Minor gaps exist, such as no dedicated statute/provision search or court/journal browsing tool, but agents can work around them via full-text search and case metadata.
Available Tools
7 toolscaselaw_get_caseARead-onlyIdempotentInspect
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
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds genuinely useful behavioral detail beyond annotations: the truncation cap (~40,000 chars) and the body_truncated/body_chars_total flags that signal when the body is longer. It does not describe auth or rate limits, but the truncation disclosure is a strong addition.
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?
Front-loaded with the core action, then structured as a two-mode explanation. Every sentence earns its place: the default behavior, the rationale for the default, and the truncation caveat for the full mode.
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 structure need not be re-explained. The description rounds out the tool by explaining the two sections, the default, and the truncation behavior. It could mention where the case_id comes from (search/lookup/graph results) since that routing context is genuinely useful for an agent.
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 67%, so the schema already documents case_id and section reasonably well. The description reinforces the section semantics and adds the summary-vs-full rationale beyond the schema's terse enum descriptions. It does not explain response_format, but the schema enum covers the two values.
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 ('Fetch one judgment by id') and immediately distinguishes the two modes via the section parameter. The description makes it clear this is a single-record retrieval, distinct from the list/search/graph siblings.
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 advises reading section='summary' first to judge relevance cheaply, and reserves section='full' for when the body text is needed. This is a clear when-to-use-which pattern with a cost-aware rationale, though it doesn't name specific sibling alternatives like caselaw_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
caselaw_get_citationsARead-onlyIdempotentInspect
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.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond annotations by specifying that the graph walk is forward-only, restricted to in-corpus cases, and that results represent the precedents relied upon by the given judgment. This is meaningful additional transparency.
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 compact and front-loaded: the first sentence states exactly what the tool does, the second clarifies the relationship with a sibling, and the final sentence gives a practical usage heuristic. Every sentence earns its place, with no filler or repetition.
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 read-only listing tool with an output schema and strong annotations, the description covers the tool's purpose, direction, scope boundary (in-corpus), relationship to sibling tools, and a concrete use case. Pagination details are handled by the input schema defaults and constraints, so nothing essential is missing for correct invocation.
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%, with only case_id documented in the schema. The description provides no additional meaning for limit, offset, or response_format, and it does not compensate for the low schema coverage. The parameters are reasonably self-descriptive, but the description itself adds no semantic value beyond the schema.
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 states a specific verb and resource ('Walk the citation graph FORWARD: list the in-corpus cases that THIS judgment cites') and explicitly differentiates from caselaw_get_cited_by, which is the sibling that lists cases citing this judgment. The directionality is unambiguous, so an agent can select it correctly without guessing.
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?
The description explicitly says to combine with caselaw_get_cited_by to traverse precedent backward and forward, and it gives a concrete usage scenario ('Most useful on RECENT judgments'). This is clear, actionable guidance that names the complementary alternative and explains when the tool provides the most value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
caselaw_get_cited_byARead-onlyIdempotentInspect
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.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond those annotations: it explains the traversal direction, that results are returned newest first, and that large result sets are possible for leading cases. No contradiction with annotations exists.
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 compact, front-loaded with the core mechanism, and every sentence adds value: direction, citation meaning, ordering, use-case guidance, and a volume warning. There is no redundant 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 read-only citation-listing tool, the description covers direction, ordering, use case, and scale. Annotations handle safety, and an output schema exists, so return-value details are not required here. Minor gaps such as explicit pagination advice or explicit sibling differentiation keep it from a perfect score.
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%, and the tool description does not compensate. It adds no meaning for limit, offset, or response_format beyond their schema titles and defaults, and it only indirectly refers to case_id as 'THIS judgment.' The low coverage means the description should have explained parameter behavior more explicitly.
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 states a precise verb and resource: 'Walk the citation graph BACKWARD: list later cases that cite THIS judgment.' It also clarifies the semantic content of the citations (followed, distinguished, relied upon), which clearly distinguishes this tool from sibling tools like caselaw_get_citations or caselaw_get_case.
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 description gives clear context for when this tool is most useful: 'Most useful on OLDER or landmark judgments' and warns that 'A leading case can have hundreds of citing cases.' It does not explicitly name alternative tools or state when not to use it, but the backward-citation direction and use-case guidance make the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
caselaw_lookup_citationARead-onlyIdempotentInspect
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 | Yes | ||
| limit | No | ||
| offset | No | ||
| journal | Yes | Law-report code, e.g. 'PLD', 'SCMR', 'CLC' | |
| 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral detail beyond those: exact-page matching, list-everything behavior when page is omitted, and the return shape being the same as caselaw_search.
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 with no filler. The core purpose is front-loaded, followed by a concrete example and the key page-omission nuance. Every sentence earns its place.
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 lookup tool with strong annotations, an output schema, and well-named parameters, the description covers the essential behavior: exact citation lookup, page omission behavior, and output compatibility with caselaw_search. Remaining details like pagination and response format are sufficiently represented by the schema and defaults.
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?
The description adds meaningful semantics for the core params: journal and year through the example, and especially page, whose omission changes the result set. However, schema description coverage is only 33%, and limit, offset, and response_format receive no descriptive help from either the schema or the description.
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 action and resource: 'Find the judgment(s) at an exact law-report citation.' The example with journal='PLD', year=1995, page=34 makes the lookup concrete, and referencing caselaw_search helps distinguish this citation-lookup tool from search-based siblings.
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 invocation context: use it when you have an exact law-report citation, and explains the important behavioral alternative of omitting page to list everything in a journal+year. It does not explicitly name sibling alternatives or say when not to use them, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
caselaw_most_citedARead-onlyIdempotentInspect
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 | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| response_format | No | markdown |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by specifying that results are ranked by citation count and that it returns landmark judgments, which goes beyond the annotations without contradicting them.
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 two sentences with zero fluff. The main purpose is front-loaded, and the landmark/ranking context is provided in a compact, readable way. Every word earns its place.
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?
Combined with the rich annotations and presence of an output schema, the description is largely complete: it states what the tool returns, how results are ranked, and the legal domain. It does not mention pagination or output format behavior, but those are covered by the input schema and output schema, so the gap is minor.
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 0%, so the description must compensate for explaining parameters, but it does not mention limit, offset, or response_format at all. While the parameter names and defaults are reasonably self-explanatory, the description provides no additional semantics or usage hints, leaving the full burden on the 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?
The description clearly states a specific verb ('List') and resource ('most-cited (landmark) judgments in the corpus'), with a precise ranking criterion ('by how many other cases cite them'). It does not explicitly differentiate from sibling tools, but the core purpose is unambiguous and distinct from search or individual case retrieval.
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 phrase 'A good entry point for the leading authorities on Pakistani law' gives contextual guidance on when to use the tool, implying it is for discovering landmark cases. However, it does not explicitly mention alternatives or state when not to use this tool versus siblings like caselaw_search or caselaw_get_cited_by.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
caselaw_searchARead-onlyIdempotentInspect
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.
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. | |
| 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.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.
caselaw_search_questionsARead-onlyIdempotentInspect
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.4/5.0
Behavior4/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), so the lower bar applies. Beyond that, the description discloses a genuinely non-obvious behavior: partial coverage with a live `coverage_note` ratio, the misleading-empty-result caveat, and the 'finding aid, not a holding' citation rule. It could still say more about ranking or result ordering, but this is well above baseline.
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 differentiator, and every paragraph carries distinct information (scope, coverage caveat, citation rule, follow-up). It runs slightly long across four sections, but no sentence is filler.
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?
An output schema exists, so return values need not be explained, and the description still supplies the coverage caveat the schema cannot. Combined with usage routing and the follow-up call, an agent has everything needed to invoke and interpret this 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 coverage is 63%, and the schema itself already documents court, judge, query, and the year filters. The description's only added parameter value is conceptual framing for `query` (legal question phrasing), while limit, offset, and response_format remain undocumented in both places. Baseline 3 for a mid-coverage schema where the description does not materially extend per-parameter meaning.
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 precise verb+resource distinction ('find judgments by the QUESTION they settle, rather than by words they contain') and defines the corpus object being searched (judgment summaries recording decided questions). This cleanly separates it from the sibling caselaw_search that matches on vocabulary.
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 gives when-to-use ('matches the shape a legal problem arrives in'), when-not (coverage is partial, empty result does not mean no such judgment exists), and the named alternative to fall back to (caselaw_search). It also routes the agent onward to caselaw_get_case for reading the 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 update
- Changed
caselaw_search_questions1 field changed- added
Input schema / properties / judgeAdded 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 updates
- Changed
caselaw_search13 fields changed- added
Input schema / properties / courtAdded 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" +} - added
Input schema / properties / journalAdded 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" +} - added
Input schema / properties / judgeAdded 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" +} - added
Input schema / properties / query / anyOfAdded value: +[ + { + "maxLength": 200, + "minLength": 2, + "type": "string" + }, + { + "type": "null" + } +] - added
Input schema / properties / query / defaultAdded value: +null - changed
Input schema / properties / query / descriptionPrevious 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." - removed
Input schema / properties / query / maxLengthRemoved value: -200 - removed
Input schema / properties / query / minLengthRemoved value: -2 - removed
Input schema / properties / query / typeRemoved value: -"string" - changed
Input schema / properties / sort / descriptionPrevious 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." - added
Input schema / properties / year_fromAdded value: +{ + "anyOf": [ + { + "maximum": 2100, + "minimum": 1900, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Earliest year (inclusive)", + "title": "Year From" +} - added
Input schema / properties / year_toAdded value: +{ + "anyOf": [ + { + "maximum": 2100, + "minimum": 1900, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Latest year (inclusive)", + "title": "Year To" +} - removed
Input schema / requiredRemoved value: -[ - "query" -]
- Changed
caselaw_search_questions3 fields changed- added
Input schema / properties / courtAdded value: +{ + "anyOf": [ + { + "maxLength": 100, + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Only this court, e.g. 'Supreme Court' or 'Lahore High Court'", + "title": "Court" +} - added
Input schema / properties / year_fromAdded value: +{ + "anyOf": [ + { + "maximum": 2100, + "minimum": 1900, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Earliest year (inclusive)", + "title": "Year From" +} - added
Input schema / properties / year_toAdded value: +{ + "anyOf": [ + { + "maximum": 2100, + "minimum": 1900, + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Latest year (inclusive)", + "title": "Year To" +}
1 tool update
- Changed
caselaw_get_case1 field changed- changed
Input schema / properties / section / descriptionPrevious value: -"'summary' = metadata + AI headnote (cheap); 'full' = + judgment text"New value: +"'summary' = metadata + headnote (cheap); 'full' = + judgment text"
7 tool updates
- First observed
caselaw_get_case - First observed
caselaw_get_citations - First observed
caselaw_get_cited_by - First observed
caselaw_lookup_citation - First observed
caselaw_most_cited - First observed
caselaw_search - First observed
caselaw_search_questions
Related MCP Connectors
Search 18M+ legal documents worldwide — case law, legislation, and doctrine across 110+ countries.
Malaysian court judgment search for Federal Court, Court of Appeal, High Court cases and parties.
Search and read Indonesian court cases. Filter by court, year, and case type.
Search Hong Kong court cases and read judgment documents.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceEnables 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.-
- AlicenseNot gradedqualityBmaintenanceEnables 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.260 npmMIT
- AlicenseAqualityBmaintenanceProvides retrieval-grounded, citation-verified access to Philippine law and compliance, including statutes, jurisprudence, and government issuances across 15 compliance domains.191Apache 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.