EAD Enterprise Suite MCP

EAD Enterprise Suite MCP サーバー

AI エージェントを通じて、署名、証拠、通知、文書を扱う EAD Enterprise Suite 用の MCP サーバーです。

クイックスタート

npx -y @g-digital/mcp-ead-enterprise-suite

または、ステップごとのセットアップガイド（5 分以内）については、ONBOARDING.mdをご覧ください。

インストール先

この MCP は、g-digital MCP distribution pipelineにより、主要なすべての MCP 配布チャネルで公開されています。ご利用のスタックに合ったものを選択してください。

チャネル	インストールコマンド／URL
npm	npx -y @g-digital/mcp-ead-enterprise-suite — npmjs.com/package/@g-digital/mcp-ead-enterprise-suite
Docker Hub	docker pull gdigital/ead-enterprise-suite:latest — hub.docker.com/r/gdigital/ead-enterprise-suite
MCP Official Registry	io.github.g-digital-by-Garrigues/ead-enterprise-suiteとして自動検出されます — registry.modelcontextprotocol.io
n8n community node	n8n の Settings → Community Nodes で @g-digital/n8n-nodes-ead-enterprise-suite をインストールします — npmjs.com/package/@g-digital/n8n-nodes-ead-enterprise-suite
Smithery	smithery mcp install g-digital/ead-enterprise-suite — smithery.ai/servers/g-digital/ead-enterprise-suite

どのチャネルでも同じ MCP サーバーの仕様が提供されます。以下のツールと環境設定は、どのインストール方法を選んでも適用されます。

認証情報が必要ですか？こちらをご覧ください：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

インストール

Claude Desktop

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

認証情報が必要ですか？こちらをご覧ください：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

Claude Code（CLI）

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

認証情報が必要ですか？こちらをご覧ください：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

Cursor

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

認証情報が必要ですか？こちらをご覧ください：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

Windsurf

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

認証情報が必要ですか？こちらをご覧ください：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

Cline

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

認証情報が必要ですか？こちらをご覧ください：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

VS Code

{
  "servers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

認証情報が必要ですか？こちらをご覧ください：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

JetBrains

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

認証情報が必要ですか？こちらをご覧ください：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

Zed

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "args": [
        "-y",
        "@g-digital/mcp-ead-enterprise-suite"
      ],
      "command": "npx",
      "env": {
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io",
        "MCP_AUTH_USER_KEY": "<PASTE_MCP_AUTH_USER_KEY_HERE>"
      }
    }
  }
}

認証情報が必要ですか？こちらをご覧ください：https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/

Claude Desktop / Claude Code

~/.claude.jsonまたはclaude_desktop_config.jsonに追加します。

{
  "mcpServers": {
    "ead-enterprise-suite": {
      "command": "npx",
      "args": ["-y", "@g-digital/mcp-ead-enterprise-suite"],
      "env": {
        "MCP_AUTH_USER_KEY": "your-user-key",
        "MCP_API_BASE_URL": "https://api-eadcustody.eadtrust.gocertius.io"
      }
    }
  }
}

Docker

docker run --rm -i \
  -e MCP_AUTH_USER_KEY=your-user-key \
  -e MCP_API_BASE_URL=https://api-eadcustody.eadtrust.gocertius.io \
  gdigital/ead-enterprise-suite:latest

環境変数

名前	必須	シークレット	説明
MCP_ALLOW_INSECURE_FILE_URL	いいえ	いいえ	evidence_create でプレーンな http:// fileUrl のダウンロードを許可するには、「true」に設定します（デフォルトでは HTTPS のみ）。プライベートアドレス／内部アドレスは、いずれの場合も拒否されます（名前解決時のチェック。ホスト型デプロイのランブックに記載されている DNS TOCTOU の制限を参照してください）。
MCP_ALLOW_UNVERIFIED_BEARER	いいえ	いいえ	受信トークンのイントロスペクションなしで MCP_HTTP_PUBLIC=true を使用する場合の回避策です。上流ゲートウェイがすでに Bearer トークンを検証している場合に限り、「true」に設定してください。サーバーは目立つ警告をログに記録し、未検証のトークンを上流に転送します。
MCP_ALLOWED_HOSTS	いいえ	いいえ	許可する Host ヘッダーをカンマ区切りで指定します。空の場合は Host の検証を無効にします（デフォルト）。設定すると、リストにない Host を含むリクエストは拒否されます。
MCP_ALLOWED_ORIGINS	いいえ	いいえ	許可するブラウザー Origin をカンマ区切りで指定します（DNS リバインディング対策）。空の場合、Origin ヘッダーを含むリクエストはすべて拒否されます。非ブラウザークライアント（CLI／SDK）は Origin を送信しないため、常に許可されます。すべて許可するには「*」を使用します。
MCP_API_BASE_URL	はい	いいえ	上流 API のルートです。必須です。このホストに対してユーザーキーをセッショントークンと交換するため、設定しないとサーバーは起動しません。
MCP_AUTH_USER_KEY	はい	はい	有効期間の長い EAD Enterprise Suite ユーザーキーです。自動的に有効期間の短いセッショントークンと交換されます。ヘッドレスまたは自動化されたアクセスでは、アカウントパスワードの代わりに使用してください。（認証情報の取得については、https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/ を参照してください。）
MCP_HTTP_HOST	いいえ	いいえ	HTTP トランスポートがバインドするインターフェースです。デフォルトは 127.0.0.1（localhost のみ）です。すべてのインターフェースで公開するには 0.0.0.0 に設定します（コンテナーでは自動的に設定されます）。
MCP_HTTP_MAX_BODY_BYTES	いいえ	いいえ	POST /mcp リクエストボディで受け付ける最大サイズをバイト単位で指定します（デフォルトは 16777216＝16 MiB。ドキュメントに記載されたツールの上限内で、Base64 ファイルのアップロードを収容できるサイズです）。サイズ超過のリクエストは、読み取り前または読み取り中に 413 JSON-RPC エラーとなります。これにより、公開デプロイにおけるメモリ枯渇型 DoS 攻撃の経路をふさぎます。注：Base64 ファイルソースには、MCP_FILE_MAX_BYTES が適用される前にこの上限が適用されます。
MCP_HTTP_PUBLIC	いいえ	いいえ	公開／マルチテナント環境で使用する場合は「true」に設定します。Host の検証を有効にし、（1）MCP_ALLOWED_ORIGINS または MCP_ALLOWED_HOSTS が設定されており、かつ（2）受信 Bearer のイントロスペクションが設定されている（MCP_SVC_INTROSPECT_URL + MCP_SVC_CLIENT_ID/SECRET）、または MCP_ALLOW_UNVERIFIED_BEARER=true が明示的に設定されていない限り、起動を拒否します（フェイルクローズ）。
MCP_SVC_CLIENT_ID	いいえ	いいえ	上記のイントロスペクションエンドポイントに対してこのサーバーが提示するクライアント ID（リソースサーバーの認証情報）です。MCP_SVC_INTROSPECT_URL と併用する場合にのみ必要です。EAD Enterprise Suite への認証には使用されません。
MCP_SVC_CLIENT_SECRET	いいえ	はい	上記のイントロスペクションエンドポイントに対してこのサーバーが提示するクライアントシークレット（リソースサーバーの認証情報）です。MCP_SVC_INTROSPECT_URL と併用する場合にのみ必要です。EAD Enterprise Suite への認証には使用されません。（認証情報の取得については、https://www.eadtrust.eu/soluciones-legaltech/enterprise-suite/ を参照してください。）
MCP_SVC_INTROSPECT_URL	いいえ	いいえ	HTTP モードで受信 Bearer を検証するための RFC 7662 トークンイントロスペクション URL です。オプトイン設定であり、MCP_HTTP_PUBLIC=true の場合は必須です。stdio（ローカル）で使用する場合は空のままにしてください。
PORT	いいえ	いいえ	ホスト型（HTTP）モードで実行する際の HTTP ポートです。stdio モードでは無視されます。

変数	必須	説明
MCP_AUTH_USER_KEY	必須	有効期間の長いユーザーキー（セッショントークンと交換されます）
MCP_OTEL_ENABLED	任意	OpenTelemetry トレーシングを有効にするには、true に設定します
MCP_API_BASE_URL	必須	上流 API のルートです。ユーザーキーの交換時にこの URL に対して認証するため、設定しないとサーバーは起動しません

同梱スキル

このパッケージには、.claude/commands/ 配下に Claude Code のスラッシュコマンドが含まれています。インストール後、Claude Code から呼び出せます。

• /getting-started — 手順を追ったワークフローガイド
• /signature-lifecycle — 手順を追ったワークフローガイド
• /notification-lifecycle — 手順を追ったワークフローガイド
• /notification-attachments — 手順を追ったワークフローガイド
• /evidence-lifecycle — 手順を追ったワークフローガイド
• /dossier-lifecycle — 手順を追ったワークフローガイド

エンドツーエンドのプロンプト例と、それによって実行されるツールの呼び出し順序については、docs/agent-prompts.md を参照してください。

REST API を直接使ってコードを作成しますか？

この MCP サーバーを経由する必要はありません。このリポジトリには、REST API を直接プログラミングするための単独の統合ガイド（認証、呼び出し順序、オプション、列挙型、注意点）である Claude Code スキル も含まれています。

• スキル： .claude/skills/gocertius-suite-api/SKILL.md — このリポジトリを Claude Code で開くと、そのまま利用できます。
• リファレンス： docs/api-integration-skill.md。

MCP ツールや n8n ノードとは独立しています。統合に適した入り口を選んでください。

利用可能なツール

このサーバーは 86 個のツール を公開しています。

ツール	説明
evidence_create	エビデンスグループ内に新しいエビデンスレコードを登録します。必要なもの：evidence_group_create → evidenceGroupId、case_file_create → caseFileId。id 用の UUID v4 を生成し、呼び出す前に SHA-256 の 16 進数ハッシュを計算してください。内部フロー：custodyType を INTERNAL にして呼び出します。レスポンスで uploadFileUrl（事前署名付き S3 URL）が返されます。uploadFileUrl にファイルのバイト列をそのまま PUT し、evidence_get/evidence_list で確認してから、必ず evidence_seal を呼び出してください。INTERNAL のエビデンスファイルが未アップロードの間はシールしないでください。外部フロー：意図的にハッシュのみのエビデンスを登録する場合に限り、custodyType に EXTERNAL を使用してください。各エビデンスには新しい UUID が必要です。以前のエビデンス作成／アップロードが失敗し、結果が不明な場合は、リトライ前に evidence_list で確認し、永続化されていないことを確認できた場合を除き、同じ id を再利用しないでください。警告：エビデンスが正常に永続化された場合でも、API が {code:'EvidenceCreateError'} を返すことがあります。
evidence_list	特定のエビデンスグループにあるすべてのエビデンスレコードを一覧表示します。必要なもの：caseFileId と evidenceGroupId。ID、タイトル、ステータス、タイムスタンプを含むページ分割された一覧を返します。
evidence_seal	エビデンスグループをシールし、適格な TSP タイムスタンプを付与します。グループ内のすべての INTERNAL エビデンスレコードが、すでに uploadFileUrl にアップロードされ、evidence_get/evidence_list で確認済みである必要があります。case_file_create → caseFileId と evidence_group_create → evidenceGroupId が必要です。evidencesCount にはグループ内のエビデンス数を設定してください。非同期：呼び出し後、グループのステータスが CLOSED に変わるまで evidence_group_list をポーリングしてから、ドシエへのリンクや証明書の生成を行ってください。
evidence_get	特定のエビデンスレコードを取得します。evidence_create → evidenceId、evidence_group_create → evidenceGroupId、case_file_create → caseFileId が必要です。認証済みの場合、ステータス（COMPLETED
evidence_group_create	ケースファイル内にエビデンスグループを作成します。case_file_create → caseFileId が必要です。id 用の UUID v4 を生成してください。evidenceType には FILE、PHOTO、VIDEO、WEB_PLUGIN のいずれかを設定します。evidenceGroupId を返します。1 つのグループに複数のエビデンスレコードを含められます。
evidence_group_list	ケースファイル内のすべてのエビデンスグループと、現在のステータス（OPEN、CLOSING、CLOSED）を一覧表示します。既存のグループを探したり、シール可能なグループを確認したりする際に使用します。caseFileId が必要です。
dossier_create	認証済みのエビデンスグループを改ざん検知可能な 1 つの PDF にまとめるドシエを作成します。case_file_create → caseFileId が必要です。リンクする前に、エビデンスグループのステータスが CLOSED である必要があります。id 用に UUID v4 文字列を生成してください。dossierId を返します。作成後、dossier_evidence_link でエビデンスをリンクし、その後 dossier_certify で認証してください。
dossier_update	既存のドシエのメタデータを更新します。dossier_create → dossierId、caseFileId が必要です。ドシエが DRAFT ステータスの間のみ使用できます。
dossier_certify	ドシエを認証し、改ざん検知可能な PDF を生成して、リンクされたすべてのエビデンスをロックします。dossier_create → dossierId、dossier_evidence_link（エビデンスがリンク済み）、case_file_create → caseFileId が必要です。非同期：DRAFT → CERTIFYING → CERTIFIED と遷移します。dossierId のステータスが CERTIFIED になるまで dossier_list をポーリングしてください。
dossier_list	ケースファイル内のすべてのドシエを一覧表示します。caseFileId が必要です。ID、名前、ステータス、作成日を含むページ分割された一覧を返します。認証の進行状況を監視するには、ステータスが CERTIFIED になるまでポーリングしてください。
dossier_list_by_user	ユーザーが所有するすべてのケースファイルを対象に、そのユーザーの全ドシエを一覧表示します。userId（session_login または session_info から取得）が必要です。ドシエがどのケースファイルにあるか不明な場合に使用してください。caseFileId がわかっている場合は dossier_list を使用します。filter、order、page に対応しています。{ data, meta.totalElements } を返します。
dossier_get	ステータス、リンクされたエビデンス、ダウンロード URL を含む、特定のドシエの詳細をすべて取得します。caseFileId と dossierId が必要です。
dossier_template_list	利用可能なドシエテンプレートを一覧表示します。前提条件はありません。テンプレート ID と、各言語の翻訳を返します。返された id を dossier_create の dossierTemplateId として使用してください。
dossier_preview	認証前のドシエの HTML プレビュー URL を返します。caseFileId と dossierId が必要です。
dossier_document_url	認証済みドシエ PDF のダウンロード URL を返します。dossier_certify（CERTIFIED ステータス）、caseFileId、dossierId が必要です。
dossier_package_url	ドシエパッケージ全体（PDF + エビデンスファイル）のダウンロード URL を返します。dossier_certify（CERTIFIED ステータス）、caseFileId、dossierId が必要です。
dossier_visibility	認証済みドシエの公開／非公開の可視性を更新します。dossier_certify（CERTIFIED ステータス）、caseFileId、dossierId が必要です。
dossier_delete	ドシエを削除します。DRAFT ステータス（認証前に破棄する場合）または CERTIFIED ステータス（認証済みドシエを完全に削除する場合）に使用できます。取り消しできません。caseFileId と dossierId が必要です。
dossier_group_certify	シール済みエビデンスグループ 1 つから、1 回の呼び出しでドシエを作成し、認証します（簡易フロー）。evidence_seal（CLOSED）、case_file_create → caseFileId、evidence_group_create → evidenceGroupId が必要です。id 用に UUID v4 文字列を生成してください。CERTIFYING ステータスの dossierId を返します。CERTIFIED になるまでポーリングしてください。
dossier_evidence_link	シール済みグループのエビデンス項目をドシエにリンクします。dossier_create → dossierId、evidence_seal（CLOSED）、case_file_create → caseFileId が必要です。エビデンス UUID の ids 配列を渡してください。異なるケースファイルのエビデンスに対して複数回呼び出せます。
dossier_evidence_list_to_link	ドシエにリンク可能なエビデンス項目（CLOSED のグループで、まだリンクされていないもの）を一覧表示します。caseFileId と dossierId が必要です。
dossier_evidence_list	ドシエの 1 つのエビデンスグループにリンクされたエビデンス項目を一覧表示します。caseFileId、dossierId、dossierEvidenceGroupId の 3 つすべてが必須です。グループに関係なくドシエ内のすべてのエビデンス項目を対象にするには、代わりに dossier_evidence_list_by_dossier を使用してください。filter、order、page に対応しています。
dossier_evidence_list_by_dossier	すべてのエビデンスグループを対象に、ドシエにリンクされたすべてのエビデンス項目を一覧表示します。caseFileId と dossierId が必要です。ドシエ全体の一覧です。dossier_evidence_list はグループごとのより限定された一覧で、dossierEvidenceGroupId も必要です。filter、order、page に対応しています。{ data, meta.totalElements } を返します。
dossier_evidence_get	ドシエにリンクされた特定のエビデンス項目の詳細を取得します。caseFileId、dossierId、evidenceId が必要です。
dossier_evidence_delete	ドシエからエビデンス項目を削除します。ドシエが DRAFT ステータスの間のみ使用できます。caseFileId、dossierId、evidenceId が必要です。
notification_document_add	通知にドキュメントを添付します。2 段階で行います。この呼び出しでファイルを登録すると、事前署名付きアップロード URL である { url } が返されます。その後、x-amz-checksum-sha256 ヘッダーを付けて、その URL に生のバイト列を PUT します。id 用の UUID v4 を生成し、呼び出す前にファイルの SHA-256 16 進数ハッシュを計算してください。ハッシュは hash に渡します。順序が重要で、誤ると送信に失敗します。受信者を追加する前にすべてのドキュメントを追加し、notification_request_send を呼び出す前に、各ドキュメントが READY_TO_SEND になるまで待ってください（notification_document_list をポーリング。約 8 秒）。受信者を追加した後に添付した場合、またはドキュメントが PENDING のまま送信した場合は、409/404 NOTIFICATION_NOT_FOUND が返されます。添付ファイルの最大数は固定の API 上限ではなく、サブスクリプションごとの設定です。数を決めつけないでください。添付ファイルを配信証明書にまとめることができます。notification_certificate_package_url を参照してください。
notification_request_create	認証済み通知リクエストを作成します。case_file_create → caseFileId が必要です。id 用の UUID v4 を生成してください。language には en_GB または es_ES を設定します。notificationRequestId を返します。送信前に notification_receiver_add で受信者を 1 人以上追加してください。重要：content フィールドは有効な HTML でなければなりません。HTML タグのないプレーンテキストは受信者のランディングページに表示されません。次の HTML 形式のみサポートされています：段落（ ）、太字（）、斜体（）、順序なしリスト（ ）、順序付きリスト（ ）。その他の HTML タグや CSS は使用しないでください。subject では特殊な書体の文字（em ダッシュ、スマートクォート）を避け、標準 ASCII の同等文字（ハイフン、直線の引用符）を使用してください。
notification_request_send	追加されたすべての受信者に認証済み通知を送信します。notification_request_create → notificationRequestId、notification_receiver_add（受信者 1 人以上）、case_file_create → caseFileId が必要です。非同期：配信を開始します。証明書を生成する前に、ステータスが SENT またはそれ以降（PARTIALLY_READ、FULLY_READ）になるまで notification_request_status をポーリングしてください。
notification_request_status	認証済み通知の配信ステータスを確認します。notificationRequestId、caseFileId が必要です。ステータス（CREATING
notification_receiver_add	通知リクエストに受信者を追加します。notification_request_create → notificationRequestId、case_file_create → caseFileId が必要です。id には UUID v4 またはカスタム文字列を使用できます。receiverId を返します。notification_certificate_get 用に保存してください。配信は常にメールで行われます。WhatsApp リンクには sendWaUrl、RCS/SMS リンクには sendSmsUrl（チャネルは端末に応じて選択されます。端末が対応している場合は RCS、そうでなければ SMS）、ワンタイムコードで受信者に確認を求める場合は otpRequired を設定します。これら 3 つのいずれかを使用する場合は、phonePrefix（+ を含む）と phoneNumber が必要です。notification_request_send を呼び出す前にすべての受信者を追加してください。ただし、通知に添付ファイルがある場合は、先に添付ファイルを追加してください（notification_document_add を参照）。
notification_certificate_get	特定の受信者について、通知の配信や閲覧／回答を証明する PDF 証明書を生成または取得します。notification_request_send、notification_receiver_add → receiverId、notificationRequestId、caseFileId が必要です。その受信者の証明書を初めてリクエストする際に id 用の UUID v4 を生成し、ポーリング時にも同じ id を再利用してください。notification_request_status が SENT またはそれ以降になってから呼び出してください。また、通知の種類が受信者の操作を想定する場合は、READ/ANSWERED の状態になるまで待つことを推奨します。証明書の生成中、最初の呼び出しで {} が返される場合があります。レスポンスに pdfUrl/documentUrl または CERTIFIED／最終ステータスが含まれるまで、notification_certificate_get をポーリング／再呼び出ししてください。バックエンドから Forbidden/Unexpected が返された場合は、証明書エンドポイントのポーリングを停止し、代わりに notification_request_status をポーリングしてください。同じ証明書 id でのリトライは、通知がより完了した状態になるか、UI にエビデンスが利用可能と表示されてから行ってください。ACCEPTED_OR_NOT 通知の場合は、中間証明書として認証可能な配信／閲覧状態になった後と、PARTIALLY_ANSWERED/FULLY_ANSWERED になった後の 2 回呼び出し、最終回答証明書を取得してください。
notification_request_list	ユーザーに表示される認証済み通知を一覧表示します。userId（session_login、session_info、または profile_get から取得）が必要です。この一覧はユーザー単位であり、ケースファイル単位ではないため、フィルターを指定しない限りすべてのケースファイルが対象です。手元にない notificationRequestId を復元する際に使用します。通知を見つける方法はこれだけです。通知ごとに id、code、subject、status、type、sentAt、receiverStats、所有する caseFile を返します。status または statuses（CREATING、DRAFT、IN_PROCESS、SENT、PARTIALLY_READ、FULLY_READ、PARTIALLY_ANSWERED、FULLY_ANSWERED）、caseFileIds、subject を対象にした search、または特定の受信者宛ての通知を見つける receiversSearch でフィルターできます。ページ分割されます。
notification_request_update	まだ送信されていない通知の subject、content、type、language を編集します。notificationRequestId と caseFileId が必要です。content は有効な HTML でなければなりません。プレーンテキストは API で受け付けられますが、受信者のランディングページには表示されません。サポートされるタグのみ使用できます： 、、、 、 。その他のタグや CSS は使用できません。subject はプレーンな ASCII 文字にし（em ダッシュやスマートクォートは使用しない）、100 文字以内にしてください。テスト済み：通知が送信されると API は 403 Forbidden を返すため、編集できるのは送信前のみです。所属するケースファイルを変更するには notification_request_case_file_move を使用してください。このツールでは移動できません。
notification_request_delete	通知を削除します。notificationRequestId と caseFileId が必要です。取り消しはできません。テスト済み：通知が送信されると API は 403 Forbidden を返します。送信済み通知は配信エビデンスであり、削除できません。別の場所に移動したいだけの場合は、代わりに notification_request_case_file_move を使用してください。
notification_request_duplicate	既存の通知から、その内容、受信者、添付ファイルをコピーして、新しい DRAFT 通知を作成します。元の通知の状態に関係なく機能するため、同じ相手に再送したり、送信済み通知をテンプレートとして再利用したりできます。id 用の UUID v4 を生成し、新しい subject を指定してください。コピー先を別のケースファイルにするには本文に caseFileId を指定し、元の通知と同じケースファイルに置くには省略してください。コピーは非同期で作成されます。作成時は受信者 0 人、ドキュメント 0 件の CREATING から始まり、その後内容が反映されるため、すぐに読み取ると空の通知に見えますが、実際には空ではありません。確認や送信の前に、ステータスが DRAFT になるまで notification_request_status をポーリングしてください。受信者もコピーされるため、notification_request_send を呼び出す前に notification_receiver_list で確認してください。そうしないと、元のリストに再び送信されます。
notification_request_case_file_move	通知を別のケースファイルに移動します。2 つの caseFileId の意味に注意してください。パスの caseFileId は通知の現在の場所、本文の caseFileId は移動先です。通知はケースファイルごとにまとめられており、複製せずにそのグループを変更する方法はこれだけです。
notification_receiver_list	通知の受信者と、各受信者の配信状態を一覧表示します。受信者ごとに id、firstName、lastName、email、phonePrefix/phoneNumber、status（INVALID、READY_TO_SEND、SENT、READ、ANSWERED、ERROR）、statusUpdatedAt、回答後の answer、emailBounced、アドレスが拒否された場合の validationError（TAKEN、IS_DEFINED、IS_INVALID）を返します。notification_request_send の前に呼び出して INVALID のアドレスがないか確認し、送信後に誰が閲覧または回答したか確認すると便利です。notification_certificate_get 用の receiverId を復元する方法でもあります。ページ分割され、id でフィルターできます。
notification_receiver_update	受信者の詳細（firstName、lastName、email、phonePrefix、phoneNumber）を修正します。receiverId、notificationRequestId、caseFileId が必要です。入力ミスのあるアドレスを修正する場合、削除して再追加すると receiverId が失われるため、このツールを使用してください。phonePrefix には + を含める必要があります（例：+34）。受信者に RCS/SMS リンク（sendSmsUrl）、WhatsApp リンク（sendWaUrl）、または OTP 確認（otpRequired）を送信する場合は、電話番号が必要です。
notification_receiver_delete	通知から受信者を削除します。receiverId、notificationRequestId、caseFileId が必要です。プラットフォームが拒否したすべてのアドレスを 1 回で削除するには、1 件ずつ削除する代わりに notification_receiver_invalid_purge を使用してください。
notification_receiver_add_bulk	受信者ごとに notification_receiver_add を呼び出す代わりに、複数の受信者を 1 回の呼び出しで追加します。receivers を配列として渡してください。各エントリには id（生成してください）、firstName、lastName、email が必要で、phonePrefix（+ を含む）と phoneNumber を指定することもできます。この一括形式では、単一受信者用ツールで使用できる受信者ごとの otpRequired、sendWaUrl、sendSmsUrl フラグは指定できません。代わりにリクエストのデフォルト（otpByDefault、sendWaUrlByDefault、sendSmsUrlByDefault）を設定してください。受信者の最大数は固定の API 上限ではなく、サブスクリプションごとの設定です。テナントやプラットフォームによって異なるため、数を決めつけずに追加し、テナントの上限を超えた場合はエラーを確認してください。notification_request_send を呼び出す前にすべての受信者を追加し、拒否されたアドレスは status INVALID として表示されるため、notification_receiver_list で結果を確認してください。
notification_receiver_invalid_purge	status が INVALID の受信者（形式不正または重複としてプラットフォームが拒否したアドレス）を、1 回の呼び出しで通知からすべて削除します。notificationRequestId と caseFileId が必要です。その他のステータスの受信者には影響しません。無効な受信者がいると送信がブロックされるため、notification_request_send の前にこのツールを実行するか、notification_receiver_update でアドレスを修正してください。そうしないと通知は送信されません。削除対象を確認するには、先に notification_receiver_list を使用してください。
notification_document_list	通知に添付されたドキュメントと処理ステータスを一覧表示します。notification_document_add の後にポーリングするためのツールです。新しく登録したドキュメントは PENDING から始まり、約 8 秒で READY_TO_SEND になります。いずれかのドキュメントが PENDING の間に notification_request_send を呼び出すと、409/404 NOTIFICATION_NOT_FOUND で失敗します。上限を設けたリトライでポーリングしてください。数秒おきに、最大 12 回程度です。notificationRequestId と caseFileId が必要です。ページ分割されます。
notification_document_delete	通知から添付ファイルを削除します。documentId（notification_document_list から取得）、notificationRequestId、caseFileId が必要です。
notification_document_download_url	送信された時点の添付ファイルへの一時リンク { downloadUrl } を返します。documentId（notification_document_list から取得）、notificationRequestId、caseFileId が必要です。添付したファイルを取得したり、受信者が受け取った内容を確認したりするために使用します。URL は事前署名付きで有効期限があるため、保存せず、必要なときに取得してください。
notification_certificate_list	1 人の受信者に対してすでに生成された配信証明書を一覧表示します。重複を生成せずに再利用できます。receiverId、notificationRequestId、caseFileId が必要です。証明書ごとに id、status（DRAFT、CERTIFYING、CERTIFIED）、language、createdAt、certifiedAt、受信者が回答を終える前に発行された中間証明書かどうかを示す partial、embeddedDocuments を返します。embeddedDocuments を「パッケージに添付ファイルが含まれている」という意味に解釈しないでください。実際のテストでは添付ファイルがある通知でも false でしたが、notification_certificate_package_url はその添付ファイルを含む ZIP を返しました。証明書が CERTIFIED になったら、notification_certificate_document_url（証明書のみ）または notification_certificate_package_url（添付ファイルも含む ZIP）でダウンロードしてください。
notification_certificate_document_url	証明書 PDF 単体の { documentUrl } を返します。添付ファイルは含まれません。certificateId、receiverId、notificationRequestId、caseFileId が必要です。証明書が CERTIFIED になるまで待ってください。生成は非同期で、CERTIFYING の間は最初の呼び出しで 404 が返されたり、空のレスポンスになったりする場合があります。過度に連続して呼び出すのではなく、回数を制限して数回ポーリングしてください。添付ファイルもまとめる場合は、代わりに notification_certificate_package_url を使用してください。
notification_certificate_package_url	証明書と通知の添付ファイルを含む ZIP の { packageUrl } を返します。「添付書類付き」の形式です。API には独立したプレビュー用フラグはありません。パッケージには添付書類が含まれ、document は証明書のみです。certificateId、receiverId、notificationRequestId、caseFileId が必要です。notification_certificate_document_url と同じ前提条件です。CERTIFIED になるまで待ってください。生成中は最初の呼び出しが失敗することがあります。
case_file_create	すべての関連操作（エビデンス、通知、署名、ドシエ）の最上位のコンテナとなる、新しいケースファイルを作成します。他の操作を行う前に、最初に呼び出してください。id 用の UUID v4 を生成してください。後続のすべての呼び出しで必要な caseFileId を返します。
case_file_list	EAD Enterprise Suite アカウント内のすべてのケースファイルを一覧表示します。アカウントに結果を絞り込むには、userId（session_login または session_info から取得）を渡してください。ID、名前、ステータスを含むページ分割された一覧を返します。
case_file_get	特定のケースファイルの詳細を取得します。caseFileId が必要です。エビデンスグループ、ドシエ、署名リクエストを作成する前に、ケースファイルが存在することを確認するために使用してください。
case_file_delete	ケースファイルと、その中に記録されたすべてのもの（エビデンスグループ、ドシエ、通知およびその証明書）を削除します。取り消しできず、確認ステップもごみ箱もありません。caseFileId が必要です。本文は返されません（HTTP 204）。case_file_list で確認してください。ユーザーからそのケースファイルの破棄を依頼された場合を除き、「整理」のために呼び出さないでください。
session_login	MCP サーバーに EAD Enterprise Suite への再認証を強制します。パラメーターは不要で、認証情報も受け付けません。サーバーは設定済みのユーザーキー（MCP_AUTH_USER_KEY）を再交換して新しいセッショントークンを取得し、その userId と有効期限を報告します。MCP サーバーは認証を自動的に管理します。401 エラーが発生した場合に限り呼び出してください。サーバーが独自の認証情報を保持していない場合（未設定、または独自の Bearer トークンを提供した場合）は、更新するセッションが存在せず、このツールは MCP_AUTH_USER_KEY を示すエラーを返します。
session_info	現在認証されているセッションの情報を取得します。userId、type（この MCP セッションの認証方式。このサーバー唯一の認証フローである UserKey が常に設定されます）、accountLoginType（別の情報で、EAD Enterprise Suite アカウント自体のログイン方式。Password または OpenId。API が省略した場合は null）、email、companyId、defaultCaseFileId を返します。ID は GET /profile を通じて解決されます。userId のみが必要な場合は、正規の情報源（id）であり、プロフィールの他の情報も返す profile_get を優先してください。必須パラメーターはありません。
profile_get	認証済みユーザー自身のプロフィールを返します。セッショントークンのみから呼び出し元を特定するため、email やその他の入力は不要で、リクエストごとの Bearer を使用するデプロイを含むすべてのデプロイで動作します。id フィールドが userId（UUID）で、case_file_list およびすべての /users/{userId}/... 操作で必要な値です。userId が必要な場合は、正規の情報源であるため session_info よりこちらを優先してください。また、通知 SSE ストリームの購読に必要な companyId と defaultCaseFileId も返します。さらに、一連のブール値である permit（{ evidences, idVerifications, notifications, chats, signatures }）も返します。これは、このアカウントで使用可能なツール群を示します。値が false の項目に対応するツールは、入力内容に関係なくすべて 403 を返し、リトライや引数の変更では解決しません。各ツール群を初めて呼び出す前に確認してください。2026-09-07 に確認した統合環境では、permit.idVerifications は false で、すべての本人確認ツールが 403 NoIdVerificationsPermit を返しました。パラメーターはありません。
use_case_list	アカウントで利用可能なユースケースを一覧表示します。ユースケースによって、許可される署名ワークフローとドキュメントの種類が定義されます。signature_request_create に必要な useCaseId の値を返します。
id_verification_video_create	1 人分のリモートビデオ本人確認を開始します。プラットフォームが対象者に連絡し、本人確認セッションを実施します。必要なもの：id（生成する UUID v4）、name、firstSurname、email、phonePrefix、phoneNumber。phonePrefix には先頭の + を含める必要があります（例：'+34'）。secondSurname は省略可能です。本文なしの HTTP 201 が返されるため、生成した id を保管してください。これが verificationId で、結果を読み取る方法は id_verification_list のみです。権限による制限があります。最初に profile_get を呼び出して permit.idVerifications を確認してください。false の場合、ここでの呼び出しはすべて code NoIdVerificationsPermit を含む 403 を返し、引数を変更しても解決しません。リトライせず、その旨を報告してください。対面での本人確認は上流で非推奨となっており、意図的に公開していません。
id_verification_list	ユーザーに属する本人確認と、それぞれの結果を一覧表示します。userId（profile_get から取得）が必要です。各項目は { id, email, name, firstSurname, secondSurname, status, identificationType, createdAt, createdBy, rejectedReason, rejectedContext } で、本人確認が成功したかどうか、失敗した場合はその理由をここで確認できます。filter、order、page に対応しています。本文を返さない id_verification_video_create の結果を確認する唯一の方法です。profile_get で permit.idVerifications === false と報告された場合、権限による制限として code NoIdVerificationsPermit を含む 403 を返します。
id_verification_contract_url	完了した本人確認 1 件の署名済み本人確認契約書を取得します。verificationId（id_verification_video_create 用に生成した id、または id_verification_list から取得した id）が必要です。注意：OpenAPI 仕様では、この操作の 200 レスポンスに本文がないと宣言されているため、正確なペイロードは未定義で、正常に動作するデプロイ環境で確認されていません。特定のフィールドを想定せず、返された内容を確認してください。profile_get で permit.idVerifications === false と報告された場合、権限による制限として code NoIdVerificationsPermit を含む 403 を返します。契約書への署名には有効な OTP が 2 つ必要なため、意図的にツールとして公開していません。
signature_group_create	CONFIGURABLE 署名リクエスト用の署名順序グループを作成します。種類：'Document'（ドキュメントを署名ラウンドにまとめます。signature_request_add_document の groupId にその id を使用）、'Signatory'（署名者を署名ラウンドにまとめます。signature_participant_create の groupId にその id を使用）、'DocumentSignatory'（特定のドキュメントを署名ラウンドにリンクします。documentId が必要）。重要：空のグループを避けてください。CONFIGURABLE リクエストを作成すると、API は index:1 の Document グループと Signatory グループをそれぞれ 1 つ自動作成します。最初のドキュメントと最初の署名者には、必ず既存の index:1 グループを使用してください（リクエストの作成直後に signature_group_list で ID を取得します）。signature_group_create を呼び出すのは、追加グループ（index:2、3…）のみです。DocumentSignatory グループが正しい index で自動生成されるように、linkToAllDocuments:true を指定して参加者を追加してください。linkToAllDocuments を指定せずに参加者を追加すると、ドキュメントにリンクされず、signature_coordinate_set が 'Signatory not found' で失敗します。
signature_group_list	CONFIGURABLE 署名リクエストのすべての署名順序グループを一覧表示します。各グループについて id、type（Document/Signatory/DocumentSignatory）、index、documentId を返します。ドキュメントや参加者を追加する前に、signature_request_create の直後に呼び出して、事前作成された index:1 グループの ID を取得してください。
signature_request_create	DRAFT ステータスの新しい署名リクエストを作成します。case_file_create → caseFileId が必要です。id 用の UUID v4 を生成してください。期限は ISO 8601 の日時で設定します（最長で約 30 日先）。requestId を返します。有効化する前に、signature_request_add_document でドキュメントを、signature_participant_create で参加者を追加してください。
signature_request_get	署名リクエストの詳細をすべて取得します。signature_request_create → requestId、case_file_create → caseFileId が必要です。ステータス、ドキュメント、参加者、期限、履歴を返します。プロセス全体の状態確認に使用してください。
signature_request_cancel	アクティブな署名リクエストをキャンセルします。activate_signature_request（ACTIVE ステータス）、requestId、caseFileId が必要です。CANCELLED に遷移します。取り消しできません。
signature_request_add_document	DRAFT の署名リクエストにドキュメントを追加します。signature_request_create → requestId、case_file_create → caseFileId が必要です。ドキュメント用の文字列 id を指定してください。この id は座標と証明書で使用する documentId になります。呼び出す前に PDF の SHA-256 16 進数ハッシュを計算してください。URL（事前署名付き S3 アップロード URL）を返します。PDF のバイト列をそのまま url に PUT する必要があります。その後、バックエンドの処理が完了してから有効化してください。API が処理済み／READY_TO_SIGN を公開する場合は、signature_request_get をポーリングしてください。レスポンスにドキュメントの処理フィールドがない場合は、PUT 成功後に少し処理時間を置き、PDF の座標を設定してから有効化し、signature_request_get で ACTIVE ステータスを確認してください。signature_document_list はドキュメント単位のステータスと signatoryCoordinatesStats（座標の前提条件の確認に便利）を報告しますが、新規追加ドキュメントのアップロード処理状況を報告するかは確認されていません。アップロード処理の確認には signature_request_get を使用してください。activate_signature_request の呼び出し後はドキュメントを追加できません。CONFIGURABLE の場合、groupId は Document タイプのグループを参照する必要があります（Signatory または DocumentSignatory は不可）。誤ったグループタイプを渡すと 'Signature group not found' が返されます。
signature_document_list	署名リクエスト内のドキュメントを、ドキュメント単位のステータスおよび各ドキュメントの統計情報とともに一覧表示します。signature_request_create → requestId、case_file_create → caseFileId が必要です。各項目は { id, requestId, groupId, status, title, fileName, fileSize, convertToPdf, participantStats, signatoryStatusStats, signatoryCoordinatesStats } です。例：status PARTIALLY_SIGNED、signatoryStatusStats { pending: 0, readyToSign: 1, signed: 1, rejected: 0 }、signatoryCoordinatesStats { defined: 2, missing: 0 }（INT で 2026-09-07 にライブ取得）。signatoryCoordinatesStats.missing === 0 は、activate_signature_request の前に必要な署名者すべてに座標が設定されていることを直接確認する方法です。このステータスが新規追加ドキュメントのアップロード処理状況も報告するかどうかは未確認です。引き続き signature_request_get を使用してください。1 つのドキュメントの署名者を確認するには signature_document_signatory_list を使用してください。
signature_document_signatory_list	署名リクエスト内の 1 つのドキュメントの署名者と、そのドキュメントに対する各署名者のステータスを一覧表示します。signature_request_add_document → documentId、signature_request_create → requestId、case_file_create → caseFileId が必要です。各項目は { id, groupId, email, firstName, lastName, status, coordinates, uniqueValidator, phonePrefix, phoneNumber, participantStats } で、status は PENDING、READY_TO_SIGN、VALIDATING、SIGNED、REJECTED のいずれかです。各 id は signatoryId です。activate_signature_request の前にドキュメント自体が READY_TO_SIGN になったか確認するには signature_request_get を使用してください。有効化後は、signature_certificate_get を呼び出す前に、すべての署名者が SIGNED になるまでここをポーリングしてください。
signature_document_observer_list	署名リクエスト内の 1 つのドキュメントのオブザーバーを一覧表示します。オブザーバーは role OBSERVER で作成された参加者で、署名はせずコピーを受け取ります。signature_request_add_document → documentId、signature_request_create → requestId、case_file_create → caseFileId が必要です。項目に含まれるのは { id, email, firstName, lastName } のみです。オブザーバーには完了すべき操作がないため、意図的に status フィールドはありません。同じドキュメントの署名者を確認するには signature_document_signatory_list を使用してください。
signature_signatory_progress_list	署名リクエスト内の 1 人の署名者に割り当てられたドキュメントと、各ドキュメントに対するその署名者の進捗状況を一覧表示します。caseFileId、requestId、signatoryId が必要です。signatoryId は role が SIGNATORY の参加者の id です。signature_participant_list または signature_document_signatory_list から取得してください。role が SIGNATORY ではない参加者の id を渡すと 404 'Signatory not found' が返されます。2026-09-07 に INT で VALIDATOR id を使用した際に確認しました。ID 空間は共通ですが、署名者単位のエンドポイントで受け付けるのは role が SIGNATORY の参加者 ID のみです。status が PENDING、READY_TO_SIGN、SIGNED、REJECTED の項目を含む { data, meta.totalElements } を返します。各項目は { id, fileName, fileSize, status } です。
signature_participant_create	DRAFT の署名リクエストに参加者を 1 人追加します。参加者を作成するエンドポイントはこれだけです。role で SIGNATORY（署名必須）、OBSERVER（読み取り専用のコピーを受け取る）、VALIDATOR（署名者が署名する前に承認必須）を選択します。signature_request_create → requestId、case_file_create → caseFileId に加えて、role、firstName、lastName、email が必要です。id はユーザー側で生成する必要があります（UUID v4）。この呼び出しは本文なしの HTTP 201 を返すため、値は返されません。生成した id が participantId であり、role SIGNATORY を指定した場合は signatoryId、role VALIDATOR を指定した場合は validatorId になります。必ず保存してください。ADVANCED 署名では、署名者に OTP を送るため phonePrefix と phoneNumber が必須です。ADVANCED では WhatsApp 配信はサポートされていません。INTERPOSITION では電話番号は省略可能で、プラットフォームが設定されていれば WhatsApp を利用できます。有効化する前に SIGNATORY を 1 人以上追加してください。role VALIDATOR の場合は groupId と linkToAllDocuments を指定しないでください。後から assign_validator_to_signatory でリンクします。一度に多数追加するには signature_participant_add_bulk を使用し、存在する参加者を再確認するには signature_participant_list を使用してください。
signature_participant_add_bulk	参加者ごとに signature_participant_create を呼び出す代わりに、DRAFT の署名リクエストに複数の参加者を 1 回の呼び出しで追加します。signature_request_create → requestId、case_file_create → caseFileId、さらに signature_participant_create と同じフィールド（各参加者用に生成する id と role を含む）を持つ participants 配列が必要です。1 回の呼び出しで異なる role を混在させることができます。本文なしの HTTP 201 が返されるため、生成した id を保存し、signature_participant_list で結果を再取得してください。
signature_participant_list	署名リクエストのすべての参加者と、それぞれに割り当てられた role（SIGNATORY、OBSERVER、VALIDATOR）、連絡先、妥当性を一覧表示します。signature_request_create → requestId、case_file_create → caseFileId が必要です。各項目は { id, requestId, groupId, role, firstName, lastName, email, phonePrefix, phoneNumber, createdAt, editable, emailBounced, valid, validationError, participantStats, documentStats } です。ID の確認に使用するツールです。項目の id は participantId であり、role が SIGNATORY の場合は signatoryId、role が VALIDATOR の場合は validatorId でもあります。filter、order、page に対応しています。
signature_participant_update	署名リクエストを有効化する前に、参加者の詳細を修正します。signature_participant_create → participantId、signature_request_create → requestId、case_file_create → caseFileId が必要です。groupId、firstName、lastName、email、phonePrefix、phoneNumber のうち、任意の項目を渡せます。role は変更できません。署名者をオブザーバーに変更するには、削除してから作成し直してください。誤ったメールアドレスやバウンスしたメールアドレスの修正に使用します。signature_participant_list は emailBounced と validationError を報告します。本文は返されません。signature_participant_list で確認してください。
signature_participant_delete	署名リクエストから参加者を 1 人削除します。signature_participant_create → participantId、signature_request_create → requestId、case_file_create → caseFileId が必要です。誤って追加した人を削除したり、role を変更したりする際に使用します（role は更新できないため、削除してから新しい role で作成します）。本文は返されません。signature_participant_list で確認してください。無効な参加者をすべて一度に削除するには、代わりに signature_participant_invalid_purge を使用してください。
signature_participant_invalid_purge	プラットフォームが無効と判定した署名リクエストの参加者をすべて、1 回の呼び出しで削除します。signature_request_create → requestId、case_file_create → caseFileId が必要です。signature_participant_list で valid: false と validationError により確認できます。通常、配信できないメールアドレスや形式不正の電話番号が原因です。本文は返されません。signature_participant_list で確認してください。参加者を削除するより詳細を修正できる場合は、signature_participant_update を優先してください。
assign_validator_to_signatory	署名リクエスト内の特定の署名者に、1 人以上の検証者を割り当てます。署名者は署名する前に検証者の承認を得る必要があります。signature_participant_create（検証者）→ validatorIds 配列内の validatorId、signature_participant_create（署名者）→ signatoryId、signature_request_create → requestId、case_file_create → caseFileId が必要です。
signature_validator_list	署名リクエスト内の 1 人の署名者に現在リンクされている検証者を一覧表示します。signature_participant_create（署名者）→ signatoryId、signature_request_create → requestId、case_file_create → caseFileId が必要です。各項目は { id, email, firstName, lastName } で、各 id は validatorId です。2 段階のモデルであることに注意してください。role VALIDATOR で参加者を作成しても、誰かに自動で紐付くわけではありません。リクエストに検証者が存在しても、assign_validator_to_signatory でリンクするまではここに表示されない場合があります。リストが空の場合は、検証者が存在しないのではなく、まだ誰にもリンクされていないことを意味します。
signature_validator_unassign	1 人の検証者を 1 人の署名者からリンク解除します。assign_validator_to_signatory を元に戻す操作です。signature_validator_list → validatorId、signature_participant_create（署名者）→ signatoryId、signature_request_create → requestId、case_file_create → caseFileId が必要です。リンクのみを解除します。検証者はリクエストの参加者として残るため、その人物自体を削除するには signature_participant_delete を使用してください。本文は返されません。signature_validator_list で確認してください。
activate_signature_request	署名リクエストを有効化し、DRAFT から ACTIVE に遷移させて、すべての署名者に署名依頼を送信します。ファイルのアップロード直後には呼び出さないでください。有効化の前提条件：リクエストが DRAFT であること、SIGNATORY が 1 人以上いること、すべてのドキュメントが事前署名付き URL にアップロード済みであること、アップロードした各ドキュメントのバックエンド処理が完了していること（公開されている場合は signature_request_get の処理済み／READY_TO_SIGN を確認し、それ以外の場合は PUT 成功後に待機します）、PDF ドキュメントの必要な署名者すべてに署名座標が設定されていること。INTERPOSITION では、利用可能かつ設定済みの場合、WhatsApp を含むシンプルな署名リンクを送信することがあります。ADVANCED では OTP に phonePrefix/phoneNumber を使用し、現在 WhatsApp 配信はサポートされていません。取り消し不可：有効化後はドキュメントや参加者を追加できません。非同期：有効化後、ステータスが ACTIVE になるまで signature_request_get をポーリングしてください。その後、documentId を指定した signature_document_signatory_list で各署名者を監視するか、signature_document_list でリクエスト内のドキュメントと署名者の集計 signatoryStatusStats を確認してください。ドキュメントが SIGNED になってから signature_certificate_get を呼び出してください。
signature_coordinate_set	PDF ドキュメントのページ上で、署名フィールドの視覚的な位置を設定します。INTERPOSITION と ADVANCED のどちらの署名でも、有効化前に PDF ドキュメントへの設定が必要です。signature_participant_create → signatoryId、signature_request_add_document → documentId、signature_request_create → requestId、case_file_create → caseFileId が必要です。座標は {page（1 起点）、x（左端からのポイント数）、y（下端からのポイント数）} の配列で指定します。ドキュメントをアップロードした後、activate_signature_request を呼び出す前に座標を設定してください。
signature_certificate_get	署名済みドキュメントの証明書 PDF を取得します。activate_signature_request（ドキュメントが完全に SIGNED）、signature_request_add_document → documentId、signature_request_create → requestId、case_file_create → caseFileId が必要です。documentUrl（署名済み PDF 証明書）を返します。非同期：documentUrl が利用可能になるまでポーリングしてください。
large_evidence_upload_initiate	EAD Enterprise Suite API に対して、エビデンスグループ用の大容量ファイルアップロードを開始します。id、caseFileId、evidenceGroupId、title、fileName、hash（SHA-256 16 進数）、fileSize（バイト）、custodyType が必要です。マルチパートアップロード ID と、各パート用の事前署名付き URL を返します。5 MB を超えるファイルに使用してください。すべてのパートをアップロードしたら、large_evidence_upload_complete を呼び出してください。
large_evidence_upload_complete	大容量ファイルのアップロードを完了し、エビデンスグループをシールします。large_evidence_upload_initiate → パートのアップロード完了、case_file_create → caseFileId、evidence_group_create → evidenceGroupId が必要です。非同期：TSP タイムスタンプの付与を開始します。status === CLOSED になるまで evidence_group_list をポーリングしてください。
large_evidence_upload_get	プラットフォームが実際に受信した大容量ファイルのアップロード量を報告します。caseFileId、evidenceGroupId、エビデンス id が必要です。fileName、totalSizeMB、chunkSizeMB、biggestUploadedOffset を返します。large_evidence_upload_complete を呼び出す前に、biggestUploadedOffset と totalSizeMB を比較し、すべてのパートが届いているか判断してください。停止したアップロードの再開や診断に使用します。
evidence_upload	ローカルファイルを 1 ステップでエビデンスとしてアップロードします。SHA-256 の計算、エビデンスレコードの登録（custodyType INTERNAL = EAD がファイルを保存）、S3 へのバイト列のアップロードを行います。手動でのハッシュ計算や PUT は不要です。内部では、必須の EAD 手順に従います。INTERNAL エビデンスを作成 → uploadFileUrl（事前署名付き S3 URL）を受け取る → ファイルのバイト列を PUT → uploaded:true を返します。case_file_create → caseFileId、evidence_group_create → evidenceGroupId が必要です。filePath（絶対ローカルパス。stdio／ローカルモードのみ）または contentBase64（ファイル内容を Base64 エンコードしたもの。約 10 MB が上限）のいずれか 1 つだけを指定してください。ファイルがローカルマシンにある場合は evidence_upload を使用してください。SHA-256 ハッシュがすでにある場合、uploadFileUrl を手動で確認／使用する場合、または公開 fileUrl がある場合は evidence_create を使用してください。このツールの成功後、evidence_get/evidence_list で確認してから evidence_seal を呼び出してください。エビデンス id を返す前にこのツールが失敗した場合は、リトライ前に evidence_list を確認してください。手動でリトライする場合は、新しい UUID を指定して evidence_create を使用してください。ローカルファイルのサイズは 1 GiB 未満である必要があります。
notification_send	1 回の呼び出しで、1 人以上の受信者に認証済み通知を送信します。通知リクエストを作成し、すべての受信者を追加して、送信します。すべての UUID をツール側で生成するため、id を渡さないでください。case_file_create → caseFileId が必要です。content は必ず HTML にしてください。プレーンテキストは API で受け付けられ、SENT と報告されますが、受信者のランディングページには表示されません。サポートされるタグのみ使用できます： 、、、 、 。その他のタグや CSS は使用できません。subject はプレーンな ASCII 文字で、100 文字以内にしてください。配信は常にメールで行われます。受信者ごとに、sendWaUrl（WhatsApp）、sendSmsUrl（端末に応じた RCS または SMS）、otpRequired（ワンタイムコード）を追加で設定できます。いずれも phonePrefix（+ を含む）と phoneNumber が必要です。受信者の最大数は固定の上限ではなく、サブスクリプションごとの設定です。このツールでは上限を適用せず、上限を超えた一括処理は API が拒否します。このツールはファイルを添付しません。添付ファイルは受信者を追加する前に登録する必要があるため、notification_send_with_attachments を使用してください。一部成功は例外ではなく結果として報告されます。リクエストは作成されたものの、受信者の追加または送信に失敗した場合でも、結果には notificationRequestId と recipientsAdded、recipientsFailed、sent:false が含まれます。下書きを破棄せずに、notification_receiver_add と notification_request_send で処理を完了できます。INVALID の受信者は送信をブロックするため、このツールは送信前に確認し、成功しない送信を試みずに invalidRecipients を報告します。最初の作成に失敗した場合は、代わりにツールがエラーを発生させます。よくある原因は、存在しない caseFileId、100 文字を超える subject、契約上の通知プランの上限到達で、これらはリトライしても解決しません。エラーが拒否ではなくタイムアウトの場合は、リトライ前に notification_request_list を確認してください。リクエストがすでに作成されている可能性があります。配信の進捗については notification_request_status をポーリングし、その後、受信者ごとに notification_certificate_get を呼び出してください。
notification_send_with_attachments	1 回の呼び出しで、1 つ以上のドキュメントを添付した認証済み通知を 1 人以上の受信者に送信します。添付ファイルがない場合は、代わりに notification_send を使用してください。このツールが別に用意されているのは、API が厳格に順序を強制し、例外を認めないためです。受信者を追加する前にドキュメントを登録して完全にアップロードし、通知を送信する前に各ドキュメントを READY_TO_SEND にする必要があります。そうでない場合、送信は 409/404 NOTIFICATION_NOT_FOUND で失敗します。このツールはその一連の処理を代行します。作成 → 各ドキュメントの登録とアップロード → READY_TO_SEND になるまで待機 → 受信者を追加 → 送信。各添付ファイルには、ローカルファイルパス、Base64 コンテンツ、HTTPS URL、n8n バイナリー参照のいずれかを指定できます。ハッシュ計算とアップロードは内部で処理されます。すべての UUID をツール側で生成するため、id を渡さないでください。case_file_create → caseFileId が必要です。content は必ず HTML にしてください。プレーンテキストは API で受け付けられ、SENT と報告されますが、受信者のランディングページには表示されません。サポートされるタグのみ使用できます： 、、、 、 。subject はプレーンな ASCII 文字で、100 文字以内にしてください。配信は常にメールで行われます。受信者ごとに、sendWaUrl（WhatsApp）、sendSmsUrl（端末に応じた RCS または SMS）、otpRequired（ワンタイムコード）を追加で設定できます。いずれも phonePrefix（+ を含む）と phoneNumber が必要です。添付ファイルの最大数と受信者の最大数は固定の上限ではなく、サブスクリプションごとの設定です。このツールではどちらの上限も適用しません。添付ファイルの処理が失敗した場合は、意図的に受信者を追加する前に処理を中止します。受信者が存在すると、API はそれ以上ドキュメントを受け付けないため、処理を続けると不足ファイルを含められない通知が作成されてしまいます。結果には下書きの notificationRequestId が含まれるため、リトライまたは削除ができます。INVALID の受信者は送信をブロックするため、このツールは送信前に確認し、失敗する送信を試みずに invalidRecipients を報告します。最初の作成に失敗した場合は、代わりにツールがエラーを発生させます。よくある原因は、存在しない caseFileId、100 文字を超える subject、契約上の通知プランの上限到達で、これらはリトライしても解決しません。エラーが拒否ではなくタイムアウトの場合は、リトライ前に notification_request_list を確認してください。リクエストがすでに作成されている可能性があります。証明書には添付ファイルをまとめることができます。notification_certificate_package_url を参照してください。

共存

この MCP サーバーは、EAD Enterprise Suite API の現在の、積極的にメンテナンスされているインターフェースです。

v1.0 より前の EAD Enterprise Suite 向け MCP サーバーを以前に使用していた場合、このサーバーがその後継であることにご注意ください。移行期間中は両方のサーバーを同時に実行できます。どちらも同じ上流 API に接続し、ローカル状態を共有しません。複数の MCP サーバーを使用する構成でツール名が重複するのを避けるため、移行完了後は一度に 1 つだけ実行してください。

ライセンス

MIT — LICENSE を参照してください。