Skip to main content
Glama
Sign In
Lex: Luxembourg Law MCP Server

Lex: Luxembourg Law MCP Server

by SFHAJJI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Lex V3

Lex shows the published text of Luxembourg and European Union law as it stood on a date, article by article, with the official source, the text's hash and a permalink. It is served at https://law.soufien.lu (open since 27 October 2026), in French and English, over the pages, a REST API and an MCP server on one origin. It does not give advice, apply the law to a situation, make its own consolidation or let a model choose an act or rank results.

How it is built, in short: the publishers' files (Formex XML from the Publications Office, Akoma Ntoso from Legilux) are parsed into relational SQLite indexes (works, dated versions and their validity intervals, articles, hashes, publisher relations), built twice and compared byte for byte; questions are parsed by deterministic parsers (ELI, CELEX, citations, dates); retrieval goes by structure first (act, version on a date, article), then lexical search over the articles' text; every answer is a typed envelope and every refusal a typed code with a mandatory payload. Releases are reproducible, signed images, checked against the release serving before them. An assistant is built to a typed answer contract (the model only plans; code validates and quotes) and is switched off until its gates pass.

Where to read more: STATUS.md (what is served, what is next), docs/OPERATING.md (how it runs), LAUNCH-CONTRACT.md (the acceptance list), and on the site itself the Developers page and "What this site holds". Work starts from v3/integration; main is the legacy line.

Local verification

dotnet test Lex.V3.slnx --configuration Release
npm test --prefix web
npm run build --prefix web
pwsh -File eng/verify-v3-tree.ps1

Available Tools

10 tools
article_historyAInspect

Every distinct text ONE provision (article/annex) has had, as validity intervals — plus its lifecycle events (inserted/removed/renumbered, renumbering detected mechanically by identical text hash). The answer to "what did Article X say over its life / when did it change".

Inputs: work (required), anchor (required).

as_ofAInspect

The state of one document as it stood on one date. Pure lookup, no ranking. mode=outline lists the provisions (articles/annexes) without text — use it first on long documents; mode=select returns only the named anchors' text; mode=full (default) returns the whole text. Every provision carries its own permalink and hash.

Inputs: date (required), work (required), mode, anchors, +1 more.

changes_in_periodAInspect

ACROSS the corpus: which works gained new versions between two dates, how many each, and when — the aggregate counterpart of diff/timeline (which cover ONE work). Use for "what changed between 2025 and 2026", "which laws changed most during the pandemic", "what moved last month". order=by_churn ranks by number of new versions; by_date (default) lists most recently changed first.

Inputs: to_date (required), from_date (required), limit, order, +3 more.

cited_byAInspect

Which ARTICLES point at this law. The reverse of the cross-references the publisher writes into its own text ("modifie par la loi du 4 juin 2020"), captured at derive time. Answers "what depends on this law", "who amended it", "is anything still referring to it" — the question legal research is actually made of, and the one a search box cannot answer.

Inputs: work (required), limit.

coverageBInspect

What we hold and what we lack, tier by tier: counts, date ranges, history_begins, known gaps. This tool exists to say what we do NOT have.

Inputs: publisher.

diffBInspect

What changed between two dates for one work: which versions applied, and where both texts are held, retrieve them via as_of to compare.

Inputs: work (required), to_date (required), from_date (required), language.

in_force_onAInspect

The set of works in force on a date, computed from validity intervals at query time, deduplicated by work. Carries a mandatory population disclosure.

Inputs: date (required), limit, offset, publisher, +1 more.

provenanceAInspect

Proof chain for one lex_id: source URI, retrieval time, record/body hashes, event chain, corpus commit, index build, stamp signature.

Inputs: lex_id (required), language.

searchAInspect

Filtered-then-ranked full-text search (FTS; filters always run before ranking). Returns hits WITHOUT body text: lex_id, dates, snippet, hash. Full state via as_of.

Inputs: query (required), as_of, limit, works, +2 more.

timelineBInspect

Every state a document has been in: validity intervals and version keys, publisher-asserted.

Inputs: work (required), limit, offset.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    Deploy Server
    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

    TDQS

    A4/5.0

    Scored across 10 tools

    Disambiguation5/5

    Each tool targets a distinct legal research need: provenance, state-at-date, document history, force status, diffing, search, provision history, coverage, citations, and corpus-wide changes. The descriptions clearly differentiate overlapping tools like timeline vs article_history and diff vs changes_in_period.

    Naming Consistency5/5

    All tool names are lowercase and use underscores for multi-word phrases, following a consistent pattern. While parts of speech vary, the formatting style is uniform, with no camelCase or mixed conventions.

    Tool Count5/5

    With 10 tools, the server is well-scoped for legal research, covering discovery, retrieval, temporal analysis, and citation tracking. Each tool serves a unique purpose without redundancy.

    Completeness4/5

    The tool surface is largely complete, offering search, document retrieval, history, diffing, force status, and citations. The only notable gap is the absence of a forward-citation tool (which laws a given law references), though this can be mitigated by reading the text via as_of.

    Maintenance

    ActivityActive
    ResponsivenessSyncing

    Resources

    Related MCP Connectors

    Related MCP Servers