澳新法研MCP

Installing modules

Modules are operator-installed via the CLI (kept off the tool surface so an LLM never triggers a large download mid-conversation):

jurisd fetch-module <name> [--version X.Y.Z]   # download + sha256-verify + atomic install
jurisd verify-module <name>                     # re-verify installed files against the manifest
jurisd list-modules                             # list installed modules (incl. refused)

The default install root is ~/.jurisd/modules/ (override with JURISD_MODULES_DIR or --modules-dir). fetch-module validates the manifest and checks the schema version before downloading any parquet, sha256-verifies every file against the manifest, installs atomically (temp-then-rename, so a half-written module never appears), and prints the licence attribution lines at install time.

Docker

./build.sh         # build the image
docker-compose up  # run locally

See docs/DOCKER.md for details.

Quick start

Example queries for AI assistants

Once connected, ask natural-language questions:

• "Find the High Court decision in Mabo v Queensland (No 2) and explain native title."
• "Search for recent NSW cases about defamation on social media."
• "What does section 18 of the Australian Consumer Law say?" (answered offline if the module is installed)
• "Find cases that cite Mabo v Queensland (No 2)."
• "Format Mabo v Queensland (No 2) [1992] HCA 23 (1992) 175 CLR 1 per AGLC4 at [64]."
• "Compare how Victoria and NSW courts have treated non-compete clauses."

Local data modules (offline recall)

These five tools serve installed offline data modules. They require the optional @duckdb/node-api dependency and at least one installed module; semantic_search_local additionally needs @huggingface/transformers. Every answer carries metadata.source = "local_module" with the module name, version, and snapshot date (plus a staleness advisory when the snapshot is old).

Full parameter tables for every tool are in docs/AGENT-GUIDE.md.

Data modules

A data module is a self-describing parquet bundle (documents, chunks, edges, unmatched citations, plus a manifest.json) published as a GitHub release asset on the jurisd-data repository. Everything needed to load and query a module — schema version, coverage, embedding descriptor, file hashes, and licence posture — is in its manifest. No out-of-band config.

Status: no modules published yet. The jurisd-data publishing repo and its first release are still being built, so jurisd fetch-module has nothing to download today (it resolves the release and fails fast with a 404). The server runs without any module — the live AustLII layer and citation tools work standalone, and the five local-recall tools report "no modules" (degrade visibly). The CLI flow below is implemented and ready for the first publish; this section documents the intended install once modules land.

Modules are queried in place: DuckDB scans the parquet on disk and never materialises a whole table into memory, so a host can install many modules (Commonwealth legislation + per-state + decisions) and stay flat in RSS.

Baseline vs domain-specialised variants

A module's identity is (name, module_version). The module_version handle distinguishes a module's variant — a baseline module is the standard build (deterministic structure, citation edges, bge-small embeddings); a domain-specialised variant is a build tuned for a particular corpus or task. Use list_data_modules to see the variant, coverage, and embedding descriptor of each installed module, and pin a specific one with the module argument on any recall tool.