Skip to main content
Glama
HiroakiKatoh

legal-impact-mapper

by HiroakiKatoh
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

Legal Impact Mapper (LIM)

法律文書の変更影響シミュレーター - 1行の変更がどこまで影響するかを即座に可視化するMCPサーバー

概要

Legal Impact Mapper は、弁護士・パラリーガル向けの MCP (Model Context Protocol) サーバーです。Claude Code、Cursor などの AI エディタから呼び出し、法律文書の1箇所を変更した際の影響範囲を構造的に分析します。

このツールがやること：

  • 契約書・法律文書をノード（事実・義務・条件等）とエッジ（依存関係）のグラフに構造化

  • ノードの変更を検出し、依存グラフを辿って影響範囲を自動伝播

  • 各影響ノードへの影響理由とリスクレベルを提示

このツールがやらないこと：

  • 文書生成

  • 要約

  • 法的助言

Related MCP server: lawink-mcp

インストール

npm install legal-impact-mapper

または、ローカルでビルド：

git clone https://github.com/HiroakiKatoh/legal-impact-mapper.git
cd legal-impact-mapper
npm install
npm run build

設定

環境変数

変数名

必須

説明

ANTHROPIC_API_KEY

Yes

Anthropic API キー

LIM_MODEL

No

使用するモデル（デフォルト: claude-sonnet-4-20250514）

Claude Desktop での設定

claude_desktop_config.json に以下を追加：

{
  "mcpServers": {
    "legal-impact-mapper": {
      "command": "node",
      "args": ["path/to/Legal_Impact_Mapper/dist/server.js"],
      "env": {
        "ANTHROPIC_API_KEY": "sk-ant-xxxxx"
      }
    }
  }
}

Cursor での設定

.cursor/mcp.json に以下を追加：

{
  "mcpServers": {
    "legal-impact-mapper": {
      "command": "node",
      "args": ["path/to/Legal_Impact_Mapper/dist/server.js"],
      "env": {
        "ANTHROPIC_API_KEY": "sk-ant-xxxxx"
      }
    }
  }
}

提供ツール

1. extract_fact_graph

テキストから事実分類ノードと依存関係グラフを抽出します。

入力:

{
  "text": "第5条（支払条件）\n甲は乙に対し、本業務の対価として月額50万円を..."
}

出力:

{
  "nodes": [
    {
      "id": "n1",
      "type": "obligation",
      "text": "甲は乙に月額50万円を支払う",
      "confidence": 0.95
    },
    {
      "id": "n2",
      "type": "timing",
      "text": "支払期限：翌月末",
      "confidence": 0.9
    }
  ],
  "edges": [
    { "from": "n2", "to": "n1", "type": "enables" }
  ]
}

2. update_fact_classification

ノードのテキストや分類を変更し、差分情報を返します。

入力:

{
  "graph": { "nodes": [...], "edges": [...] },
  "node_id": "n2",
  "new_text": "支払期限：翌月10日",
  "mark_verified": true
}

出力:

{
  "graph": { "nodes": [...], "edges": [...] },
  "changed_node_ids": ["n2"],
  "diff_summary": {
    "modified_nodes": 1,
    "details": [
      {
        "id": "n2",
        "old_text": "支払期限：翌月末",
        "new_text": "支払期限：翌月10日"
      }
    ]
  }
}

3. analyze_impact

変更ノードから影響範囲を分析し、理由とリスクレベルを返します。

入力:

{
  "graph": { "nodes": [...], "edges": [...] },
  "changed_node_ids": ["n2"]
}

出力:

{
  "changed_node_ids": ["n2"],
  "affected_node_ids": ["n1"],
  "directly_affected": ["n1"],
  "indirectly_affected": [],
  "explanations": [
    {
      "node_id": "n1",
      "node_text": "甲は乙に月額50万円を支払う",
      "reason": "支払タイミングが短縮されるため甲の資金負担に影響",
      "impact_level": "direct"
    }
  ],
  "risk_level": "medium",
  "warning": "この変更は支払条件だけでなく契約全体の資金設計に影響します"
}

使い方の流れ

Step 1: extract_fact_graph(text)     → テキストをグラフ化
Step 2: update_fact_classification() → ノードを変更
Step 3: analyze_impact()             → 影響範囲を分析

実践例：業務委託契約の支払期限変更

  1. グラフ化: 契約書テキストを extract_fact_graph に渡す

  2. 変更: 「支払期限：翌月末」→「支払期限：翌月10日」に update_fact_classification で変更

  3. 影響分析: analyze_impact で影響範囲を確認

    • 直接影響：支払義務のキャッシュフロー変化

    • 間接影響：支払留保条項の運用負荷増加

    • 潜在影響：契約バランスの再交渉リスク

主要機能

世界線分岐（group_id）

同一事実に対する複数の解釈を group_id で管理し、法的評価の分岐を表現します。

{
  "id": "n6a", "type": "interpretation",
  "text": "アルバイトとしての就労",
  "group_id": "employment_type"
},
{
  "id": "n6b", "type": "interpretation",
  "text": "正社員としての雇用",
  "group_id": "employment_type"
}

弁護士修正保護（user_verified）

弁護士が修正したノードは user_verified: true となり、以降のLLM再生成から保護されます。

開発

npm install          # 依存パッケージのインストール
npm run build        # TypeScriptのビルド
npm test             # テストの実行
npm run dev          # 開発モード（watchビルド）

ライセンス

ISC

Available Tools

3 tools
analyze_impactAnalyze ImpactA

【いつ使う】update_fact_classificationで変更したノードの影響範囲を確定するとき。必ずupdate後のgraphとchanged_node_idsを渡すこと。 【入力】graph: 更新済みFactGraph / changed_node_ids: update_fact_classificationが返したchanged_node_idsリスト 【出力】{ changed_node_ids, affected_node_ids, directly_affected, indirectly_affected, explanations, risk_level, warning? }。affected_node_idsが空の場合は影響なし確定。 【注意】affected_node_ids: []の場合は編集作業は不要（そこで処理を打ち切ること）。risk_level=highの場合はwarningを必ず確認し、変更スコープを再検討すること。編集対象は changed_node_ids + affected_node_ids に対応する原文箇所のみ。それ以外の条文には一切触れないこと。

ParametersJSON Schema
NameRequiredDescriptionDefault
graphYes現在のFactGraph
changed_node_idsYes変更されたノードのIDリスト

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully explains behavior: output structure, handling of empty affected_node_ids (stop processing), risk_level=high warning, and constraints on editing scope. 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 well-structured with clear headings (usage, inputs, outputs, notes). Every sentence adds value, and it is concise despite covering many aspects.

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 complexity (2 required params, nested objects, no output schema), the description is very complete: it explains output structure, behavioral notes, and editing constraints. No gaps.

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%, so baseline is 3. The description adds meaning by clarifying that 'graph' must be the updated FactGraph and 'changed_node_ids' must come from update_fact_classification's output, enhancing understanding beyond 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's purpose: determining the impact range after using update_fact_classification. It specifies the context and distinguishes from siblings by indicating it is used after updating classifications.

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 provides explicit when-to-use (after update_fact_classification) and required inputs. While it doesn't explicitly state when not to use it, the context is clear enough for correct invocation.

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

extract_fact_graphExtract Fact GraphA

【いつ使う】法律文書テキストを初めてグラフ化するときのみ呼ぶ。同一文書に対して2回目以降は不要（内部でLLMを呼ぶため高コスト）。 【入力】text: 契約書・法律文書・事実関係の記述（最大50,000文字） 【出力】FactGraph: { nodes: FactNode[], edges: Edge[] }。各ノードはid/type/text/confidenceを持ち、競合解釈にはgroup_idが付与される。エッジはfrom/to/typeで依存関係を表す。 【注意】このgraphオブジェクトをそのまま後続の update_fact_classification と analyze_impact に渡すこと。

ParametersJSON Schema
NameRequiredDescriptionDefault
textYes構造化対象のテキスト（契約書、法律文書、事実関係の記述など）

TDQS

A4.6/5.0
Behavior4/5

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

No annotations exist, so description carries full burden. It discloses high cost due to LLM usage, the output structure (FactGraph with nodes/edges/confidence/group_id), and that it should be called once per document. Does not mention side effects or idempotency, but the core behavioral traits are transparent.

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?

Structured into sections (when to use, input, output, note). Every sentence provides essential information with no redundancy. Front-loaded with critical usage guidance.

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 no output schema, description adequately outlines output structure and interaction with siblings. Lacks details on error handling or behavior for exceeding character limit, but covers the main workflow sufficiently.

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 already describes 'text' parameter. Description adds value by specifying max 50,000 characters and acceptable content types (contracts, legal documents, factual relations), going beyond 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 explicitly states 'extract fact graph from legal document text' and distinguishes from sibling tools by noting it is for first-time usage only, with the output passed to update_fact_classification and analyze_impact. The verb 'graph' and resource 'legal document text' are clear.

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?

Provides explicit when-to-use ('only when graphing for the first time'), why not to call again ('high cost from internal LLM'), and what to do with output ('pass directly to siblings'). No ambiguity about the intended workflow.

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

update_fact_classificationUpdate Fact ClassificationA

【いつ使う】弁護士がノードの内容（条文テキストや分類）を変更するとき。extract_fact_graphの出力graphを受け取って呼ぶ。 【入力】graph: 現在のFactGraph / node_id: 変更対象のノードID / new_text: 新しいテキスト / new_type: 新しい分類（任意）/ mark_verified: 変更後にuser_verified=trueでロックするか（デフォルトtrue） 【出力】{ graph: 更新済みFactGraph, changed_node_ids: 変更されたノードIDリスト, diff_summary: { modified_nodes, details } }。changed_node_idsをそのままanalyze_impactに渡すこと。 【注意】user_verified=trueのノードは変更を拒否し、changed_node_ids=[]で返る。再編集が必要な場合はgraph内の該当ノードのuser_verifiedをfalseに書き換えてから再呼び出しすること。mark_verified=true（デフォルト）の場合、変更後のノードは以後自動的にロックされる。

ParametersJSON Schema
NameRequiredDescriptionDefault
graphYes現在のFactGraph（extract_fact_graphの出力）
node_idYes変更対象のノードID
new_textYesノードの新しいテキスト
new_typeNoノードの新しい分類タイプ（任意）
mark_verifiedNo変更後にuser_verified=trueとマークするか（デフォルト: true）

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavior: user_verified=true blocks modifications, after a successful edit with mark_verified=true the node becomes locked, and the output structure includes changed_node_ids and diff_summary. It also explains the return value when a node is locked.

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 well-structured with clear sections (use case, input, output, notes) and is appropriately sized. It includes all necessary information without redundancy, though it could be slightly more concise.

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?

The description is highly complete given the tool's complexity (5 parameters, nested objects, no output schema). It covers input, output, edge cases (locked nodes), and integration with sibling tools. No gaps remain.

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%, so baseline is 3. The description adds value by listing parameters in a structured format with their purposes and defaults (e.g., mark_verified defaults to true). It also explains the output structure, which the schema does not provide.

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 explicitly states the verb-resource ('update fact classification') and when to use it (lawyer changes node content). It distinguishes from siblings by mentioning it takes the output of extract_fact_graph and its output is fed to analyze_impact.

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 context for usage: 'When a lawyer changes the content of a node (text or classification)'. It also provides exclusion criteria: user_verified=true nodes reject changes, requiring setting user_verified=false first. Additionally, it instructs to pass changed_node_ids to analyze_impact.

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. 3 tool updatesv0.1.0
    • First observedanalyze_impact
    • First observedextract_fact_graph
    • First observedupdate_fact_classification
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Scored across 3 tools

Disambiguation5/5

Each tool serves a distinct, non-overlapping purpose: extract_fact_graph creates the graph, update_fact_classification modifies a node, and analyze_impact computes the ripple effects. An agent can clearly distinguish when to use each tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (analyze_impact, extract_fact_graph, update_fact_classification) using snake_case and clear action verbs, making them predictable and easy to understand.

Tool Count4/5

With 3 tools, the set is minimal but covers the essential workflow for the server's purpose. Each tool earns its place, though the count is slightly low for a broader legal document analysis platform.

Completeness3/5

The tools cover the core workflow (create, update, analyze), but lack features like reading the graph directly, deleting nodes, or managing multiple documents. Minor gaps exist that an agent may need to work around.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers