What can you do with this server?

This server provides corpus-based access to Pakistani federal statutes and Supreme Court judgments for legal research and citation verification. Core capabilities: * Search federal statutes (pk_search_laws): Keyword search across 967 federal statutes with title-weighted ranking, returning law IDs, titles, snippets, and source URLs. (First call downloads and caches a ~47 MB corpus.) * Retrieve full statute text (pk_get_law): Fetch complete statute text by corpus ID, truncated at ~300,000 characters for large laws. * Search Supreme Court judgments (pk_case_search): Full-text search across 1,414 Supreme Court of Pakistan judgments, returning case IDs, row indices, snippets, and source URLs. * Retrieve full judgment text (pk_get_decision): Fetch complete judgment text by dataset row index or registry citation (e.g., Crl.A. 93/2013). * Verify legal citations (pk_verify_citations): Extract and validate Pakistani legal citations from any text (drafts, memos, pleadings) — checking statute sections, act coordinates, Constitution articles, and Supreme Court registry citations — with hallucination detection, range hints for non-existent sections, content mismatch warnings, and reporting of unverifiable gaps. Design properties: * Every response includes a stable eli_uri, human_readable_citation, and source_url. * Read-only; all tool calls are logged with a SHA-256 input hash, duration, and status. Key limitations: * Corpora are static snapshots (statutes: 2025-01-30; judgments: 2024-07-26) — amendments and newer judgments are not reflected. * The judgment corpus is a subset of the Court's full output; a missing case does not prove non-existence.

How do I use pk-eli-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pk-eli-mcp search for Pakistan Penal Code" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

pk-eli-mcp

by matematicsolutions

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

pk-eli-mcp

MCP server for Pakistani law: 967 federal statutes and 1,414 Supreme Court of Pakistan judgments, full text, with a strict citation contract on every response.

Pakistan publishes no machine-readable legal API, so this connector is corpus-based: it serves two public HuggingFace mirrors of official sources instead of querying a government endpoint live.

Collection	Source	Snapshot	License
Federal statutes (967)	Pakistan_Laws_Dataset, collected from pakistancode.gov.pk PDFs (Ministry of Law and Justice)	2025-01-30	ODC-BY 1.0
Supreme Court judgments (1,414)	supreme-court-of-pak-judgments	2024-07-26	MIT

Honest limits, stated up front: both collections are static snapshots. Amendments after 2025-01-30 and judgments after 2024-07-26 are absent, and the judgment corpus is a subset of the Court's output. Every response repeats this in dataset_note. Verify currency against pakistancode.gov.pk and scp.gov.pk before relying on a provision.

Tools

Tool	What it does
`pk_search_laws`	Keyword search over the 967 federal statutes (title-weighted). First call downloads the 47 MB corpus once, then serves from cache.
`pk_get_law`	Full statute text by `law_id` (truncated at ~300,000 characters).
`pk_case_search`	Server-side full-text search over the Supreme Court judgments.
`pk_get_decision`	One judgment's full text, by `row_idx` or registry `case_id`.
`pk_verify_citations`	Anti-hallucination check: extracts Pakistani legal citations from any text and verifies each against the corpus.
`pk_coverage`	Declare what this connector covers, when each family was captured, and - explicitly - what it does NOT cover. Every gap carries a fallback.

Related MCP server: turath

Citation verification (`pk_verify_citations`)

Run it on a drafted answer, memo or pleading before it reaches a reader. The tool extracts every checkable citation and verifies it against the corpus:

statute sections: section 302 of the Pakistan Penal Code, section 10A of the Pakistan Study Centres Act, 1976, sections 6 and 7 of ..., sub-section (1) of section 6 of ...;
act coordinates: Act No. XLV of 1860, Ordinance No. LII of 2000 (Roman or Arabic);
Constitution articles: Article 184(3) of the Constitution (the tail is required - a bare Article 5 could be any instrument and is deliberately ignored);
Supreme Court registry citations: Crl.A. 93/2013, Criminal Appeal No. 93 of 2013.

The semantics are deliberately hard:

A cited section that does not exist makes the whole result HALLUCINATION_DETECTED with isError=true, plus a range hint of what does exist (section 999 does not exist in this act; 59 sections are machine-detectable in its text, numbered section 1-66).
NO_CITATIONS_FOUND is not a success - it means there was nothing to check.
A parenthetical description right after a citation (section 302 of the Pakistan Penal Code (punishment of qatl-i-amd)) is content-checked against the real provision text with a character-trigram match. A mismatch is a review signal, never a hard block.
Everything the tool could NOT check is listed in a structured gaps field. The judgment corpus is a subset and roughly half the statute PDFs carry no machine-readable coordinate header, so an unresolvable citation is reported as out_of_corpus ("existence UNKNOWN, not disproven"), never as a hallucination.

The parse-verify-report pattern is adapted from korean-law-mcp (MIT) - see THIRD_PARTY.md. The same pattern shipped first in it-eli-mcp v0.6.0; the fleet rollout plan lives in docs/VERIFY-ROLLOUT.md.

Citation contract

Pakistan has not deployed ELI. Every response still carries the fleet contract:

eli_uri - a stable, resolvable URL: the canonical pakistancode.gov.pk PDF for statutes, the dataset row URI for judgments. Never invented; see eli_note.
human_readable_citation - e.g. THE PRIVATISATION COMMISSION ORDINANCE, 2000 or Supreme Court of Pakistan, Crl.A. 93/2013.
source_url - where a human can read the same document.

Install

uvx pk-eli-mcp          # or: pip install pk-eli-mcp

Claude Code:

claude mcp add pk-eli-mcp -- uvx pk-eli-mcp

Or drop .mcp.json.example into your project as .mcp.json.

Windows 11 with Smart App Control

Smart App Control blocks unsigned executables, which covers uvx.exe, pip.exe and the pk-eli-mcp.exe launcher that pip writes at install time. The python.exe and py.exe from the python.org installer are signed by the Python Software Foundation, so running the module through the interpreter works:

python -m pip install pk-eli-mcp
python -m pk_eli_mcp

pip.exe is blocked for the same reason, so install with python -m pip, not pip install. If python is not on PATH, use the Windows launcher: py -3 -m pk_eli_mcp.

{ "mcpServers": { "pk-eli-mcp": { "command": "python", "args": ["-m", "pk_eli_mcp"] } } }

Do not turn Smart App Control off to work around this - it cannot be re-enabled without reinstalling Windows.

Configuration

Env	Default	Purpose
`PK_ELI_CACHE_DIR`	`~/.matematic/cache/pk-eli`	Corpus file + HTTP cache
`PK_ELI_AUDIT_DIR`	`~/.matematic/audit`	JSONL audit log (one line per tool call)

Development

python -m venv .venv && .venv/Scripts/pip install -e ".[dev]"   # Linux/macOS: .venv/bin/pip
ruff check src tests
pytest tests/test_instructions_drift.py tests/test_corpus.py   # offline
pytest tests/test_smoke.py                                     # live (downloads the corpus)

Governance

Read-only by design: the server can search and fetch, never write. Every tool call appends an audit line (~/.matematic/audit/pk-eli-mcp.jsonl) with a SHA-256 input hash, duration and status. See CONSTITUTION.md for the rules this connector is built under and DISCOVERY.md for how the sources were chosen.

License

Apache-2.0 for this code. The datasets keep their own licenses (ODC-BY 1.0 and MIT); the underlying texts are Government of Pakistan public legal documents.

Available Tools

6 tools

pk_case_searchA

Read-onlyIdempotent

Full-text search over 1,414 Supreme Court of Pakistan judgments (server-side).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	max results, 1-20 (default 10).
`query`	Yes	free-text keywords, e.g. ``"qatl-i-amd"`` or ``"fundamental rights"``.

Output Schema

ParametersJSON Schema

Name	Required	Description
`items`	No
`query`	Yes
`dataset_note`	No
`total_matches`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by noting that the search is 'server-side' and operates on a fixed dataset of 1,414 judgments, which provides additional behavioral context beyond what annotations state. No contradictions.

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 a single sentence of 14 words, front-loaded with the key action 'Full-text search'. Every word is purposeful without redundancy or unnecessary detail.

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?

Given the tool's simplicity (2 parameters, full schema coverage, annotations, and output schema exists), the description sufficiently covers what the tool does, its scope, and server-side behavior. It does not need to explain return values due to output schema, and the count of judgments provides useful context. Minor gap: no mention of sorting or pagination, but overall adequate.

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 100% with descriptions for both parameters: query (free-text keywords with example) and limit (max results, default 10, range 1-20). The description adds only general context ('Full-text search over 1,414 judgments') but does not enhance parameter meaning beyond schema. Baseline 3 is appropriate.

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 clearly states the verb 'search' and the resource 'Supreme Court of Pakistan judgments', and it distinguishes from sibling tools like pk_get_decision (retrieving a specific decision) and pk_search_laws (searching laws). The scope is specific: 'over 1,414 judgments'.

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 provides the context of use (searching judgments) but does not explicitly state when to use versus alternatives or when not to use. The sibling tools give some implicit differentiation, but no direct guidance on exclusion criteria.

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

pk_coverageA

Read-onlyIdempotent

Declare what this connector covers, how it is sourced, and what it does NOT cover.

Call this before telling a user that the law "does not contain" something, and whenever a search comes back empty: the absence may be a gap in this connector rather than in the law. Every gap carries a fallback saying where to look instead.

Returns: Coverage with families, an as-of note, and a non-empty list of known gaps.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	No
`families`	No
`as_of_note`	Yes	States what the dates mean, and what they do not promise.
`known_gaps`	No	Never empty. An empty list would mean 'not checked', not 'no gaps'.

TDQS

A4.9/5.0

Behavior5/5

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds behavioral context beyond these: it explains that empty search results may reflect connector gaps, that gaps include fallback references, and that the returned Coverage has an as-of note and known gaps. This complements rather than repeats the annotations.

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 but complete. It front-loads the core purpose, adds actionable usage guidance in the next block, and briefly describes the return structure. Every sentence earns its place with no redundancy.

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 zero-parameter tool with strong annotations and a defined output schema, this description is fully sufficient. It tells the agent when to call the tool, how to interpret the result, and what the returned Coverage object contains. Nothing else is needed for safe and correct invocation.

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?

The tool has zero parameters, so the baseline is 4. The description receives full credit for not needing to document parameters and for clarifying what the tool returns instead.

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 uses a specific verb ('Declare') and resource ('what this connector covers') and clearly differentiates the tool as a coverage declaration rather than a search or retrieval operation. It explicitly states both what is covered, how it is sourced, and what is NOT covered, making its purpose unambiguous.

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 gives explicit when-to-use guidance: call it before telling a user the law 'does not contain' something, and whenever a search comes back empty. It also explains the reasoning — absence may be a connector gap rather than a legal absence — and mentions the fallback for each gap, which is strong implementation guidance.

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

pk_get_decisionA

Read-onlyIdempotent

Fetch one Supreme Court judgment's full text, by row index or registry citation.

ParametersJSON Schema

Name	Required	Description	Default
`case_id`	No	registry file id, e.g. ``"Crl.A.93_2013.pdf"`` (used when ``row_idx`` is not given).
`row_idx`	No	0-based dataset row index from ``pk_case_search`` (preferred).

Output Schema

ParametersJSON Schema

Name	Required	Description
`case_id`	No
`content`	No
`eli_uri`	No
`row_idx`	Yes
`eli_note`	No
`byte_size`	No
`truncated`	No
`source_url`	No
`dataset_note`	No
`human_readable_citation`	No

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, destructiveHint=false, so the safety profile is clear. The description adds that it fetches the 'full text', which is a behavioral detail not fully covered by annotations. There is no contradiction.

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?

Single, front-loaded sentence with no wasted words. Efficiently conveys the tool's action, resource, and input options.

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 simple fetch tool with complete schema annotations (100% coverage) and an output schema, the description is sufficiently complete. It clarifies the input options and the result ('full text'), meeting all needs for correct invocation.

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 100% with detailed descriptions for both parameters. The description only summarizes the input methods ('by row index or registry citation'), adding marginal value beyond the schema. Baseline 3 is appropriate.

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?

Description uses specific verb 'Fetch' and clearly identifies the resource as 'one Supreme Court judgment's full text'. It distinguishes from siblings by specifying the input methods (row index or registry citation), making the tool's purpose unambiguous.

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 states the tool is used to fetch a judgment by row index or citation, implying it is the appropriate tool when you have one of these identifiers. It does not explicitly exclude scenarios or name alternatives, but the context from sibling tools (e.g., pk_case_search for searching) provides clarity.

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

pk_get_lawA

Read-onlyIdempotent

Fetch the full text of one federal statute. Large statutes are truncated.

ParametersJSON Schema

Name	Required	Description	Default
`law_id`	Yes	the corpus file name from ``pk_search_laws``, e.g. ``"administrator00532129aba2e10fe634ab8fbd94c50b.pdf"``.

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	No
`title`	No
`law_id`	Yes
`content`	No
`eli_uri`	No
`eli_note`	No
`byte_size`	No
`truncated`	No
`source_url`	No
`dataset_note`	No
`human_readable_citation`	No

TDQS

A4.5/5.0

Behavior4/5

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

Beyond annotations (readOnlyHint, idempotentHint), the description discloses that large statutes are truncated, which is a behavioral trait affecting the result. This adds value beyond the safety profile annotations.

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 consists of two concise sentences, no wasted words. The main action is front-loaded, and the truncation caveat is placed second.

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

Completeness5/5

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

Given the tool's simplicity (one parameter, clear purpose, output schema present), the description sufficiently covers the essential information: what it does, how to get the input, and a critical limitation (truncation). No further details are necessary.

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?

The parameter 'law_id' is described in the schema as 'the corpus file name', but the description adds concrete context: it comes from pk_search_laws and provides an example format. With 100% schema coverage, this extra context elevates clarity.

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 clearly states the action: 'Fetch the full text of one federal statute.' It also specifies the scope (one statute) and a key constraint (truncation for large statutes). This differentiates it from siblings like pk_case_search and pk_get_decision.

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 implicitly guides usage by mentioning truncation, warning agents that large statutes may not be fully returned. It also references pk_search_laws for obtaining the law_id, suggesting a preceding search step. However, explicit when-to-use or when-not-to-use compared to siblings is absent.

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

pk_search_lawsA

Read-onlyIdempotent

Keyword search over Pakistan's 967 federal statutes (title-weighted ranking).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	max results, 1-50 (default 10).
`query`	Yes	free-text keywords, e.g. ``"penal code"`` or ``"electronic crimes"``.

Output Schema

ParametersJSON Schema

Name	Required	Description
`items`	No
`query`	Yes
`dataset_note`	No
`total_matches`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, etc. Description adds behavioral context: searches 967 statutes, uses title-weighted ranking. This goes beyond annotations by revealing ranking logic, though doesn't detail output format or pagination.

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?

Single sentence (10 words) with no waste. Front-loaded with key purpose: 'Keyword search over Pakistan's 967 federal statutes'.

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 output schema present, description needn't detail return values. Mentions statute count and ranking method – adequate for search tool, but could add brief guidance on query syntax or ranking implications.

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 covers 100% of parameters with descriptions. Tool description reinforces query as free-text keywords and adds ranking context, exceeding baseline value.

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?

Description states 'Keyword search over Pakistan's 967 federal statutes (title-weighted ranking)' – specific verb (keyword search), resource (Pakistan's federal statutes), and distinguishing feature (title-weighted ranking). Clearly differentiates from siblings like pk_case_search and pk_get_law.

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?

No explicit when-to-use or when-not-to-use instructions. Sibling tool names provide contextual hints (e.g., pk_get_law for direct access, pk_case_search for cases), but description does not directly guide selection.

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

pk_verify_citationsA

Read-onlyIdempotent

Verify Pakistani legal citations found in a text against the corpus.

Extracts statute sections ("section 302 of the Pakistan Penal Code", "section 10A of the Pakistan Study Centres Act, 1976"), act coordinates ("Act No. XLV of 1860"), Constitution articles ("Article 184(3) of the Constitution") and Supreme Court registry citations ("Crl.A. 93/2013"), then checks each against the local corpus. A parenthetical description right after a citation is content-checked with a trigram match (mismatch = review signal). Non-existent sections come back with a range hint of what DOES exist.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	the text to verify (an LLM answer, a memo, a pleading).
`max_citations`	No	cap on citations to verify (1..30, default 15).

Output Schema

ParametersJSON Schema

Name	Required	Description
`gaps`	No
`total`	Yes
`status`	Yes
`summary`	Yes
`citations`	No
`dataset_note`	No
`failed_count`	Yes
`warning_count`	Yes
`verified_count`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds significant behavioral context: extracts specific citation types, checks against corpus, performs trigram content matching for parenthetical descriptions, and provides range hints for non-existent sections. No contradictions.

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?

Five well-structured sentences, each adding unique value. Front-loaded with main purpose. No extraneous information.

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

Completeness5/5

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

Given the tool's complexity (multiple citation types, trigram matching, range hints), the description is complete. Output schema exists (as per context signals), so return values need not be explained. All essential behavioral aspects are covered.

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 100% with descriptions for both parameters. Description adds value beyond schema by explaining what types of citations are expected in 'text' and the default cap for 'max_citations', plus content-checking behavior. Provides extra meaning not present in 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?

Description clearly states the tool verifies Pakistani legal citations, lists specific citation types (statute sections, act coordinates, Constitution articles, Supreme Court registry citations) and explains the verification process. Distinguishes from sibling tools which are search-oriented.

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?

Description implies use for verifying citations in legal texts like LLM answers, memos, or pleadings, but does not explicitly state when to use vs alternatives or when not to use. Sibling tools are for searching, not verification, so guidance is implicit but not explicit.

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 updatev0.4.3Aug 28, 2026
- Addedpk_coverage
1 tool updatev0.3.0Jul 13, 2026
- Addedpk_verify_citations
4 tool updatesv0.1.0Jul 10, 2026
- First observedpk_case_search
- First observedpk_get_decision
- First observedpk_get_law
- First observedpk_search_laws

Install Server

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

TDQS

A4.2/5.0

Scored 2026-09-02 00:10 across 6 tools

Disambiguation5/5

Each tool maps to a distinct operation: statute search, statute retrieval, case search, case retrieval, coverage disclosure, and citation verification. The search/get pairs are clearly separated by corpus, and pk_verify_citations has a specialized purpose that does not overlap with the plain search tools.

Naming Consistency3/5

Most tools follow a pk_ + verb_noun pattern such as pk_search_laws and pk_get_decision, but pk_case_search reverses the order and pk_coverage is a bare noun rather than a verb phrase. The pk_ prefix provides some consistency, but the naming conventions are mixed overall.

Tool Count5/5

Six tools is well-scoped for a legal research connector: two search/retrieve pairs cover the two corpora, plus coverage and citation verification add necessary meta-capabilities. Each tool earns its place and none feel redundant.

Completeness4/5

The set covers search and retrieval for both federal statutes and Supreme Court judgments, plus citation verification and explicit gap disclosure, which is strong for a read-only legal corpus. The main limitation is that large statutes are truncated with no continuation mechanism, and case retrieval relies on row index or registry citation rather than broader citation formats.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

LegalSearch B
ai.roopslaw
Public Indian legal search MCP for Roop judgments, statutes, and corpus grounding.
Search Legal & Compliance Government Data
621
Pakistan Case Law A
com.pakistancaselaw
Search 197,000+ Pakistani judgments by keyword, citation, or the legal question they settle.
Legal & Compliance Search
71
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
Pasal.id — Indonesian Law AOAuth
io.github.Aturio
Task-oriented MCP for Indonesian law: search, resolve citations, read laws, and MK decisions.
Government Data Search Legal & Compliance
21

Related MCP Servers

canlii-mcp
Legal & Compliance Government Data
Vaquill-AI
A
license
A
quality
C
maintenance
An MCP server providing AI assistants access to Canadian case law and legislation metadata from CanLII across all jurisdictions, supporting search and citation relationships.
Updated 4 days ago (2026-09-06 17:37 UTC)
7
5
5
MIT
turath
dihannahdi
A
license
Not graded
quality
C
maintenance
MCP server to search and retrieve passages from a corpus of 7,872 classical Islamic books via the Sahifah API, with full citations and mu'tabar filtering.
Updated 2 months ago (2026-07-20 01:35 UTC)
7
MIT
eqanun-api
Legal & Compliance Government Data Search
beerbottle90
A
license
Not graded
quality
B
maintenance
MCP server for Azerbaijan's official legal-acts database (e-qanun.az), enabling search, metadata retrieval, and full-text access to legislative and judicial documents.
Updated 5 days ago (2026-09-05 16:48 UTC)
MIT
us-law-mcp
Legal & Compliance Search Government Data
seelpeed-debug
A
license
A
quality
B
maintenance
MCP server for U.S. federal law that enables searching the U.S. Code, CFR, Federal Register, case law, and bills, with citation verification against primary sources to prevent hallucinations.
Updated a month ago (2026-07-31 12:44 UTC)
11
MIT

pk-eli-mcp

Tools

Citation verification (pk_verify_citations)

Citation contract

Install

Windows 11 with Smart App Control

Configuration

Development

Governance

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Citation verification (`pk_verify_citations`)