Skip to main content
Glama
Sign In
enesjakozh
legalize-mcp

legalize-mcp

by matematicsolutions
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

legalize-mcp

非公式。 legalize-dev プロジェクトとは無関係であり、承認も受けていません。 legalize.dev API に対応した公式の legalize-dev MCP サーバーが開発中です。 こちらは代わりに公開 Git コーパスを読み取ります。

1つのMCPサーバー、32の法域(うちEU 21)。 legalize-dev コーパス上の読み取り専用 Model Context Protocol サーバー — 各国の法律を law-as-git として保存: 1法律につき1つのMarkdownファイル、各改正はGitコミット、それぞれに8フィールドのELIスタイルfrontmatter (Legalize Format Spec v0.2) が付いています。このコネクタはApache-2.0です。

Matematic Solutions が eu-legal-mcp ラインの一部として構築しました。単一国の *-eli-mcp コネクタとは異なり、こちらは単一のサーバーから多数の法域に対応します。基盤となるコーパスがすでに1つの形式に正規化されているためです。

存在理由

すべてのレスポンスには、このラインの他の部分が使用する引用契約が含まれます:

  • source_url — 法律自体のfrontmatterに記載された公式政府ソース(例: boe.es、riigiteataja.ee、legifrance.gouv.fr)。決して捏造されません。

  • github_url — 実際に読み取られた検証可能な legalize-dev コピー。

  • human_readable_citation — "<title> (<identifier>)"。

RODO/GDPR準拠かつセルフホスト可能です: GitHubへの読み取り専用GET以外、ユーザーのマシンから何も外部に出ません。

Related MCP server: lawyer-mcp

法域

EU: at be cz de ee es eu fi fr gr ie it lt lu lv nl pl pt ro se sk · その他: ad ar ch cl co kr li no uk us uy

最新のリストは legalize_list_countries を呼び出してください(絞り込むには eu_only=true を追加)。

ツール

Tool

Keyless?

Purpose

legalize_list_countries

✅

法域の一覧(コード、名前、EUフラグ、リポジトリ)。

legalize_search_laws

GITHUB_TOKEN が必要

国の法律内のキーワード検索 → law_id + スニペット。

legalize_get_meta

✅

frontmatterのみ(低コストな引用確認)。

legalize_get_law

✅

law_id による完全なメタデータ+本文。過去バージョンは sha= を渡す。

legalize_list_reforms

✅

法律の改正タイムライン(コミット)。SHAは legalize_get_law に渡す。

legalize_coverage

このコネクタがカバーする内容、各ファミリーの取得時期、そしてカバーしない内容を明示的に宣言します。すべてのギャップにはフォールバックがあります。

law_id はMarkdownのファイル名ステムです(例: スペイン憲法の BOE-A-1978-31229、エストニアの数値ID)。legalize_search_laws または公式の引用から取得してください — 曖昧なタイトル検索はありません。

インストール

uvx legalize-mcp           # run directly
# or
pip install legalize-mcp

Claude Code (.mcp.json):

{
  "mcpServers": {
    "legalize": { "command": "uvx", "args": ["legalize-mcp"] }
  }
}

Windows 11とSmart App Control

Smart App Controlは署名のない実行ファイルをブロックします。これには uvx.exe、pip.exe、およびpipがインストール時に書き込む legalize-mcp.exe ランチャーが含まれます。python.orgインストーラーの python.exe と py.exe はPython Software Foundationによって署名されているため、インタープリター経由でモジュールを実行すれば動作します:

python -m pip install legalize-mcp
python -m legalize_mcp

pip.exe も同じ理由でブロックされるため、pip install ではなく python -m pip でインストールしてください。python がPATHにない場合は、Windowsランチャーを使用します: py -3 -m legalize_mcp。

{ "mcpServers": { "legalize-mcp": { "command": "python", "args": ["-m", "legalize_mcp"] } } }

これを回避するためにSmart App Controlをオフにしないでください — Windowsを再インストールしない限り再び有効にできません。

GITHUB_TOKEN (または GH_TOKEN) は任意です — legalize_search_laws にのみ必要で、legalize_list_reforms のGitHubレート制限も解除します。

設定

環境変数

デフォルト

目的

GITHUB_TOKEN / GH_TOKEN

—

コード検索を有効化。レート制限を解除。

LEGALIZE_AUDIT_DIR

~/.matematic/audit

JSONL監査ログの場所 (AI Act 第12条)。

ガバナンス

すべてのツール呼び出しは ~/.matematic/audit/legalize-mcp.jsonl に1行を追記します(入力ハッシュ、所要時間、ステータス — ペイロードは含みません)。すべてのツールは読み取り専用かつ冪等です。CONSTITUTION.md を参照してください。

開発

python -m venv .venv && .venv/Scripts/python -m pip install -e ".[dev]"
.venv/Scripts/python -m pytest -q          # offline unit tests
.venv/Scripts/python -m ruff check src tests

帰属

立法データ © 各管轄の国家当局(各法律の source を参照)。コーパスの正規化は legalize-dev プロジェクトによるものです。

コーパスのライセンスは国ごとに異なり、MITではありません。 MITライセンスは legalize-dev のパイプラインとツールを対象としています。各国のリポジトリは、それぞれの公式ソースから継承した条件を保持しています - legalize-es はBOE再利用条件に従い、ソースの引用が必須です; legalize-at はCC BY 4.0です; その他は異なります。テキストを参照、引用、再配布する前に、各国のリポジトリを確認してください。 コーパスをMITとして扱うと、実際に負っている帰属義務をスキップすることになります。

Enrique Lop (legalize-dev) による issue #18、2026-08-24 の訂正。 このコネクタはコーパスを再配布しません。オンデマンドで読み取るだけです。

Available Tools

5 tools
legalize_get_lawA
Read-onlyIdempotent

Fetch a law's metadata and full text by id (optionally at a historical commit).

NameRequiredDescriptionDefault
shaNooptional commit SHA for a historical version (from ``legalize_list_reforms``).
law_idYesthe filename stem (e.g. ``"BOE-A-1978-31229"``).
countryYesISO-3166 alpha-2 code (e.g. ``"es"``).

Output Schema

NameRequiredDescription
shaNoGit commit SHA if a historical version was requested.
rankNoCountry-specific legal text type.
extraNoCountry-specific frontmatter fields.
titleNo
law_idYesOfficial identifier (the .md filename stem).
statusNoin_force | repealed | ...
contentYesFull law text (Markdown, frontmatter stripped).
countryYes
byte_sizeNo
github_urlYesRaw provenance URL on github.com/legalize-dev.
source_urlNoOfficial source URL (frontmatter `source`).
last_updatedNo
publication_dateNo
human_readable_citationNo

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already provide safety profile (readOnly, idempotent, non-destructive). The description adds that it returns both metadata and full text, which is beyond what annotations cover. 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?

Single sentence, no wasted words, front-loaded with action and resource. Every part 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?

Given the input schema has full descriptions and an output schema exists, the description is complete for the tool's purpose. It mentions the key optional feature (historical commit) and the fact it returns both metadata and full text.

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%, so the schema already describes all parameters. The description reinforces the purpose but does not add new meaning beyond stating 'by id' and the optional historical commit, which is already clear from 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 uses a specific verb 'Fetch' and identifies the resource 'a law's metadata and full text' with a clear method 'by id (optionally at a historical commit)'. It distinguishes from siblings like legalize_get_meta by indicating it returns both metadata and full text, and from legalize_list_reforms by noting the optional commit SHA.

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?

Explicitly states when to use: when you have the law ID and optionally want a historical version using the SHA from legalize_list_reforms. However, it does not explicitly state when not to use or provide alternatives beyond the implied sibling context.

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

legalize_get_metaA
Read-onlyIdempotent

Fetch only a law's frontmatter metadata (no body) - cheap for citation checks.

NameRequiredDescriptionDefault
law_idYesthe filename stem.
countryYesISO-3166 alpha-2 code.

Output Schema

NameRequiredDescription
rankNoCountry-specific legal text type.
extraNoCountry-specific frontmatter fields.
titleNo
law_idYesOfficial identifier (the .md filename stem).
statusNoin_force | repealed | ...
countryYes
github_urlYesRaw provenance URL on github.com/legalize-dev.
source_urlNoOfficial source URL (frontmatter `source`).
last_updatedNo
publication_dateNo
human_readable_citationNo

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and no destructive hint. The description adds valuable behavioral context by noting the tool is 'cheap', indicating low cost or fast performance, which is beyond what annotations provide.

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?

A single sentence that is front-loaded with key action and resource, no wasted words. Every part 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?

Given the existence of an output schema, return values need no explanation. The description fully covers the tool's role: fetching only metadata, cheap, for citation checks, and distinguishes from siblings. No gaps.

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%, so parameters are well-documented. The description does not add further meaning to the parameters beyond the schema, staying at baseline 3.

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 (fetch), resource (law's frontmatter metadata), and distinguishes it from sibling tools like legalize_get_law by explicitly saying 'no body'. The phrase 'cheap for citation checks' further clarifies the purpose.

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 implies usage for citation checks and distinguishes from legalize_get_law (full body). It provides clear context but does not explicitly state when not to use or list alternatives beyond the implied distinction.

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

legalize_list_countriesB
Read-onlyIdempotent

List the jurisdictions available in the legalize-dev corpus.

NameRequiredDescriptionDefault
eu_onlyNoif true, restrict to EU member states.

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description merely restates the list action without adding behavioral context. It does not contradict annotations.

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?

The description is a single, clear sentence with no wasted words. However, it could include a brief note about the output format or purpose without losing conciseness.

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

Completeness3/5

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

Given the low complexity (1 optional param, no required fields, annotations present, output schema exists), the description is minimally adequate but lacks additional context that could help an agent, such as mentioning that this tool returns country names or codes.

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 description coverage is 100%, so the single boolean parameter is already documented. The description does not add any extra meaning or usage details 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 clearly states the tool lists jurisdictions in the legalize-dev corpus. It uses a specific verb (list) and resource (jurisdictions), and distinguishes from sibling tools that deal with laws, reforms, and metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like legalize_get_meta, nor does it provide any context on prerequisites or limitations.

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

legalize_list_reformsA
Read-onlyIdempotent

List the reform history (commits) of a law - the legislative timeline.

NameRequiredDescriptionDefault
limitNomax reforms, newest first (1-100, default 20).
law_idYesthe filename stem.
countryYesISO-3166 alpha-2 code.

Output Schema

NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds context by specifying 'reform history (commits)' and 'legislative timeline,' but does not elaborate on ordering, pagination, or potential nuances beyond the schema.

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 that is front-loaded with the core action. No redundant or unnecessary words; every part contributes to clarity.

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 presence of an output schema (not shown but indicated), the description is fairly complete. It could hint at the return structure (e.g., 'reform history includes dates and changes'), but the output schema likely covers that.

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?

Input schema has 100% coverage with each parameter having a description (e.g., 'ISO-3166 alpha-2 code', 'filename stem'). The description adds no additional meaning to parameters beyond what the schema provides, so baseline score of 3 applies.

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 'List the reform history (commits) of a law - the legislative timeline,' which specifies the verb (list) and resource (reform history of a law). It effectively distinguishes from siblings like legalize_get_law (likely gets current law) and legalize_search_laws (search).

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 implies usage for viewing legislative timeline, but does not explicitly state when to use this tool versus alternatives. No exclusion or when-not-to-use guidance is provided.

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

legalize_search_lawsA
Read-onlyIdempotent

Search a jurisdiction's laws by keyword (GitHub code search; requires a token).

NameRequiredDescriptionDefault
limitNomax hits (1-100, default 10).
queryYeskeyword(s) to find inside the law texts.
countryYesISO-3166 alpha-2 code (e.g. ``"ee"``, ``"es"``).

Output Schema

NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds value by disclosing the token requirement and the underlying GitHub code search mechanism, which are not present in annotations. However, it does not detail pagination behavior or error handling beyond the limit parameter.

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, front-loaded with the action, and includes the critical token note in parentheses. No extraneous words, making it efficient and easy to parse.

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 has three parameters, full schema coverage, and an output schema (not shown), the description provides sufficient context for the core operation. However, it could briefly mention result scope (e.g., returns matching law snippets) to complete the picture.

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 each parameter having a description. The description does not add new semantic information beyond the schema, so it meets the baseline for full schema coverage without additional parameter insight.

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 tool searches a jurisdiction's laws by keyword, specifies it uses GitHub code search, and notes the token requirement. This distinguishes it from siblings like legalize_get_law (retrieve a specific law) and legalize_list_countries (list jurisdictions).

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 implies search use but does not explicitly guide when to use this tool over alternatives. The token requirement is mentioned but no when-to-use or when-not-to-use guidance is provided, leaving the agent to infer based on tool name alone.

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. 5 tool updatesv0.1.1
    • First observedlegalize_get_law
    • First observedlegalize_get_meta
    • First observedlegalize_list_countries
    • First observedlegalize_list_reforms
    • First observedlegalize_search_laws
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.2/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: retrieving full law text, retrieving metadata only, listing available countries, listing reform history, and searching laws. No ambiguity.

Naming Consistency5/5

All tools follow the consistent pattern of 'legalize_' prefix followed by verb_noun (e.g., get_law, list_countries, search_laws). Perfectly uniform.

Tool Count5/5

With 5 tools, the server covers core operations for a legal document retrieval system without being sparse or bloated. Well-scoped.

Completeness5/5

The server provides full retrieval (by ID), metadata-only retrieval, jurisdiction listing, reform timeline, and keyword search. For a read-only legal database, this is complete.

Maintenance

ActivitySlowing
ResponsivenessNo recent community issues

Resources

Related MCP Connectors

Related MCP Servers