> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Didit MCP 詳細設定・トラブルシューティング・セルフホスト

> Didit MCPの役割と権限、アプリ間の動作、ホスト型カタログ、分岐ワークフロー、Webhook、トランスポートの詳細、トラブルシューティング、セルフホストについて解説します。

## スコープと役割の権限

コネクターは`didit:management`および`didit:verification`のスコープで動作します(3つ目の`didit:staff`も公開されていますが、Didit社内スタッフのアカウントにのみ関係します)。両方の制限がすべての呼び出しに適用されます。トークンには承認したスコープが含まれ、**その範囲内で何ができるかはコンソールでの役割によって決まります**。実際のアクセス範囲は両者の共通部分となるため、`didit:verification`のみを承認した場合、`OWNER`であっても管理系の機能は利用できません。

各ツールはバックエンドの1つの権限(`read:sessions`、`write:workflows`、`delete:lists`など。ツールごとの権限は[ツールリファレンス](https://docs.didit.me/ja/integration/mcp/tools.md)に記載)に対応しています。サーバーは、トークンのイントロスペクションが返す組織の権限を用いてその権限を事前チェックします。この動作は`MCP_PERMISSION_MODE`で制御します。

| モード | 動作 |
| - | - |
| `shadow`(デフォルト) | すべてのツールが一覧に表示されます。役割で実行できない呼び出しはバックエンドに送られ、バックエンドが`403`を返します。判定結果はサーバーの監査ログに記録されます。 |
| `enforce` | 役割で実行できないツールは`tools/list`から除外されます。そのようなツールを呼び出すと、該当する権限を示す`missing_scope`エラーが返されます。 |
| `off` | 事前チェックを行いません。 |

MCPが役割を超えて権限を昇格させることはありません。あるツールで`403`が返された場合、それは役割にその権限がないことを意味しており、接続全体が失敗したわけではありません。

***

## アプリと組織をまたぐスコープの解決

Diditの管理APIはアプリケーション単位でスコープが設定されています(`/organization/{org}/application/{app}/…`)。MCPはこのスコープを自動で解決します。

* **組織とアプリが1つずつの場合** → 自動的に解決されるため、IDを渡す必要はありません。
* **複数のアプリがある場合** → アプリ横断ツール(`didit_session_search`、`didit_transaction_search`、`didit_case_search`、`didit_vendor_user_search`、`didit_vendor_business_search`、`didit_workflow_search`、`didit_analytics`)は、1回の呼び出しで**すべて**のアプリを集約し、各行に`organization_id`/`application_id`のタグが付きます。
* アプリ単位の一覧ツール(`didit_session_list`、`didit_transaction_list`、`didit_case_list`、`didit_vendor_user_list`、`didit_vendor_business_list`、`didit_workflow_list`)は、アプリを指定しない場合**すべてのアプリを自動的に対象とする**ため、アプリが多数あっても単純な「セッションを一覧表示して」がそのまま機能します。1つのアプリに絞り込むには、`organization_id`と`application_id`を渡してください。

`didit_context_get`を使うと、すべての組織とアプリケーション(およびそのID)を1回の呼び出しで確認できます。各アプリケーションの`mode`(`live`または`sandbox`)も返されるため、アプリケーション名から環境を推測しないでください。サンドボックスのアプリケーションでは、`didit_session_create`に`sandbox_scenario`を渡して、課金されないテスト実行ができます。

***

## ホスト型カタログの内容

ホスト型コネクターでは**169個のツール**を利用できます。このほかに17個のInvestigatorツールも一覧に表示されますが、これらは組織でInvestigatorが有効になっている場合にのみ動作します。さらに2つのツール、`didit_org_top_up`(Stripeチェックアウト)と`didit_org_reveal_application_api_key`(生のシークレット)は、OAuthで認証されたすべての呼び出し元の`tools/list`から非表示になっています。アカウント設定用の5つのツール(`didit_account_*`)はリモートサーバーから完全に除外されており、リモートでは実行を拒否します。リモートコネクターがツールの引数として認証情報を受け取ることは決して許されないためです。ローカルのstdioサーバーではこれらすべてを利用でき、合計193個になります。

一覧に表示される各ツールには、MCPアノテーション(`readOnlyHint`、`destructiveHint`、`openWorldHint`、`title`)と`outputSchema`、さらにその領域(Sessions、Workflows & Questionnaires、Transactions (AML)など)を示す`_meta["anthropic/toolGroup"]`ラベルが付いています。Claudeなどのクライアントは、これらのアノテーションを使ってコネクターのツールを読み取り専用、書き込み、破壊的操作のグループに分類します。

***

## 分岐ワークフロー

シンプルなワークフローは機能をフラットに並べたリストです。**条件分岐ロジック**（ステータスによる却下、抽出フィールドに基づくルーティング、一致結果によるステップの制御、Document AIリクエストの追加など）を扱う場合、MCPはDiditの**ノードグラフ**（コンソールのビジュアルビルダーと同じ構造）を操作します。グラフは`{ start_node, nodes }`で構成され、各ノードは`feature`、`branch`、`status`（終端）、`action`、`webhook`のいずれかです。分岐ルールは、`kyc.extra_fields.profession`のような抽出フィールドに対して**`fuzzy_match`**（文字列フィールド用。`score`で0〜100の類似度しきい値を指定）などの演算子をサポートします。また、`DOCUMENT_AI`機能ノードは書類（例: 資金証明）をリクエストします。

### 既存のワークフローを編集する (推奨)

実際のワークフローは**大きな**機能設定を持っています。OCRの`documents_allowed`許可リストだけで150 KB+になることがあり、さらにPOAリストや電話番号の国別リストも含まれます。そのため、グラフ全体を読み込んで再送信**しないでください**。代わりに、小さな**オペレーション**で編集します。

**1. 特定と確認**

`didit_workflow_search { workflow_id }`は、すべてのアプリを横断してワークフローを見つけます。`didit_workflow_get_graph`は、大きな設定を**要約**した状態で構造を返します（オーバーフローすることはありません。生の値が必要な場合は`include_config: true`を渡します）。`didit_workflow_get_field_definitions`は、分岐に使えるフィールドと有効な演算子を一覧表示します。

**2. オペレーションで編集**

`didit_workflow_edit_graph`は、`set_next`、`set_node`、`set_branches`、`merge_node_config`といった少数の小さなオペレーションを受け取ります。MCPは**完全なグラフをサーバー側で**取得し、オペレーションを適用して検証し、**ドラフト**を自動作成して保存します。許可リストはバイト単位でそのまま保持され、リクエストを経由することはありません。検証に失敗すると`applied: false`が返されます（何も保存されません）。

**3. レビューと公開**

`publish`する（コンソールまたは`didit_workflow_publish`経由）まで、レビュー可能なドラフトのままです。公開中のバージョンには一切手が加えられません。

たとえば、本人確認の後に**既存のパイプラインに合流する**分岐を挿入する場合、送信するのは次の内容だけです。OCRノードの`next`を新しい分岐に付け替え、分岐、終端の`Declined`ノード、`DOCUMENT_AI`ステップ（その`next`は元の後続ステップを指す）を追加します。他の10個のノードとその許可リストには手が加えられません。

> *「本人確認の後、却下された場合は却下する。職業が『Software Engineer』にほぼ一致（80%以上）する場合は資金証明をリクエストする。その後は続行する。」* → 1つの`branch`ノード: `kyc.status == Declined` → `Declined`ステータスノード。`kyc.extra_fields.profession` `fuzzy_match` "Software Engineer" スコア80 → `DOCUMENT_AI`資金証明ノード → そして、パイプラインに戻る**それ以外**のパス。

> [!NOTE]
>
> **分岐には必ず明示的な「それ以外」が必要です。** キャッチオール（どの条件にも一致しない場合に進むパス）は、`rules`が空の分岐でなければなりません（例: `{ "id": "else", "rules": [], "goto": "<liveness>" }`）。分岐ノードの単なる`next`は使えません。MCP（およびバックエンド）は分岐ノードの`next`を自動的に「それ以外」の分岐に変換するため、「それ以外」が見えない曖昧なエッジとして分岐が表示されることはありません。

**新規**ワークフローをゼロから作成するには、`didit_workflow_validate_graph`の後に`didit_workflow_set_graph`（完全なグラフ）を使用するか、`didit_workflow_build_graph`を使ってシンプルな機能仕様から保存せずに完全なグラフを組み立てます。シンプルな`didit_workflow_create`でも、この同じノードグラフとして保存されます。MCPは`features`リストを、自動判定ステータスで終わる連結された機能ノードとして組み立てるため、機能が実際に実行されます（デフォルトでは公開されます。未公開のままにするには`status: "draft"`を渡します）。完全なJSON構造については、[ワークフローの作成 → 分岐とノードベースのワークフロー](https://docs.didit.me/ja/management-api/workflows/create.md)を参照してください。

### MCPによるNFCスキップ理由の分岐

新しいグラフの場合は、次のように依頼します。

> *「本人確認の後にNFCを行うドラフトワークフローを作成してください。`nfc.skip_reason`が`DEVICE_WITHOUT_NFC`または`DOCUMENT_WITHOUT_CHIP`の場合はセッションをレビュー中にし、それ以外の場合は承認してください。明示的な『それ以外』の分岐を残し、保存前にグラフを検証してください。」*

エージェントは`didit_workflow_get_field_definitions`、`didit_workflow_validate_graph`、`didit_workflow_set_graph`の順に呼び出す必要があります。既存のワークフローの場合は、次のように依頼します。

> *「ワークフロー`26d33c04…`を編集してください。NFCノードの後で、既知の7つの`nfc.skip_reason`値のいずれかに該当する場合はレビュー中にルーティングし、既存のNFC成功パスを明示的な『それ以外』として保持してください。ドラフトとして保存し、公開はしないでください。」*

エージェントは`didit_workflow_search`、`didit_workflow_get_graph`、`didit_workflow_get_field_definitions`、`didit_workflow_edit_graph`の順に呼び出す必要があります。編集ツールは小さなオペレーションをサーバー側で適用するため、無関係なノードや大きな許可リストは保持されます。7つの値、`equals`/`in`ルール、null時の動作、順序どおりに並べた完全なグラフについては、[ワークフローの作成 → NFCが実行されなかった理由で分岐する](https://docs.didit.me/ja/management-api/workflows/create.md#nfcが実行されなかった理由で分岐する)を参照してください。

### 機能設定と許可リスト

機能ノードの`config`は、そのノードが受け付ける内容を制限します。`didit_workflow_get_feature_config_schema`は、各機能が受け取るすべてのキーを型とデフォルト値とともに返します。また、2つのカタログツール（`didit_workflow_get_id_verification_methods_catalog`、`didit_workflow_get_kyb_registry_catalog`）は、設定が依存するサーバー側の情報を提供します。標準のOCR許可リストは、国ごと → 書類ごと → オブジェクトという構造です: `{ "<ISO3>": { "<CODE>": { "enabled": 1 } } }`（例: `{ "ESP": { "P": { "enabled": 1 } } }`）。MCPは検証の前に**より扱いやすい形式を標準形式に変換**するため、この構造を手書きする必要はありません。

| 渡せる形式 | 正規化後 |
| - | - |
| 書類タイプの配列: `["PASSPORT"]` | **すべての**国でその書類（全世界でパスポートのみ） |
| 書類の**名前**または**コード**: `PASSPORT`/`P`、`NATIONAL_ID`/`ID`、`DRIVER_LICENSE`/`DL`、`RESIDENCE_PERMIT`/`RP`（`SSC`、`HIC`、`TC`も可） | 標準コード |
| `"ALL"`国キー: `{ "ALL": { "P": 1 } }` | すべての国に適用 |
| スカラーフラグ: `{ "ESP": { "P": 1 } }` | `{ "ESP": { "P": { "enabled": 1 } } }` |
| 完全に省略 | すべての書類、すべての国 |

`PROOF_OF_ADDRESS`の`poa_languages_allowed`も同じ考え方で、言語の配列（`["es"]`）またはマップ（`{ "es": 1 }`）を渡せます。これらの指定方法は、MCPに機能設定を渡すすべての場所に適用されます。対象は`didit_workflow_create`の機能、および`set_graph` / `edit_graph` / `validate_graph`のノード`config`です。

## レスポンスの形式 (V3コントラクト)

すべてのツールは、基盤となるRESTエンドポイントのJSONをそのまま返します。知っておくべき点は2つあります。

* **同期ツール** (ワークフロー、請求、単体の`verify_*`、リスト管理) は最終結果をその場で返します。同じターン内で結果に基づいて処理してください。
* **セッションの作成は非同期です**。`didit_session_create`はユーザーが手続きを完了するための`url`を返し、判定はWebhookで送信されるか、`didit_session_get_decision`で取得できます。

判定のキーは**常に複数形の配列**で、各エントリに`node_id`が含まれます (`id_verifications[]`、`liveness_checks[]`、`face_matches[]`、`aml_screenings[]`、`poa_verifications[]`、`phone_verifications[]`、`email_verifications[]`、`database_validations[]`、`reviews[]`、およびKYBの`registry_checks[]`、`document_verifications[]`、`key_people_checks[]`)。[データモデル](https://docs.didit.me/ja/reference/data-models.md)と[検証ステータス](https://docs.didit.me/ja/integration/verification-statuses.md)を参照してください。

***

## Webhookの処理

エージェントからポーリングするのではなく、Webhookで最終的な判定をバックエンドに配信させてください。

1. エージェントが`label`、公開HTTPSの`url`、`webhook_version: "v3"`、`subscribed_events` (通常は`["status.updated", "data.updated"]`) を指定して`didit_webhook_create`を1回呼び出します。レスポンスでは署名用シークレットが伏せられており、`didit_webhook_get`と`didit_webhook_list`でも同様です。コンソールの**Webhooks**からコピーし、`DIDIT_WEBHOOK_SECRET`として保存してください。
2. バックエンドは、すべての配信で正規の**X-Signature-V2**ヘッダーを検証します。手順は`shortenFloats` → `sortKeys` → `JSON.stringify` (Unicodeはエスケープしない) → HMAC-SHA256 → `timingSafeEqual`です。`abs(now − X-Timestamp) > 300`秒の場合は拒否してください。
3. `event_id`で重複を排除します。**5 秒**以内に`2xx`を返し、重い処理はキューに移してください。
4. Diditは`5xx` / `404`の場合に最大**2回**再試行し (約1分後、次に約4分後)、その後は配信を破棄します。失敗した配信はコンソールの**Deliveries**タブから再送できます。

エージェントが行うのは受信側の*接続設定*だけで、エージェント自身が待ち受けることはありません。仕様の全体は[Webhook](https://docs.didit.me/ja/integration/webhooks.md)を参照してください。

***

## トランスポートとエンドポイント

| エンドポイント | 用途 |
| - | - |
| `POST https://mcp.didit.me/mcp` | MCPエンドポイント (Streamable HTTP)。`GET`と`DELETE`には`405`を返します。サーバーはステートレスで、リクエストごとに新しいサーバーインスタンスを作成し、終了させるべきサーバー起点のストリームやセッションを保持しません。 |
| `GET https://mcp.didit.me/healthz` | ヘルスチェック: `{ "status": "ok", "service": "didit-mcp-server", "version": "5.1.1" }`。 |
| `GET https://mcp.didit.me/.well-known/oauth-protected-resource/mcp` | RFC 9728の保護リソースメタデータ (オリジンのルートでも提供)。 |

このエンドポイントは新旧両方のプロトコル世代に対応しています。すべてのメッセージで2026-07-28以降のプロトコルバージョンを固定するクライアントは、`initialize`ハンドシェイクを省略して`server/discover`を呼び出せます。それより前のクライアント (Claude Code、Cursor、SDKベースのクライアント) はすべて、標準のStreamable HTTPハンドシェイクを変更なしで使用します。CORSは開放されているため、ブラウザベースのクライアント (Claude Webコネクタ、MCP Inspector) もクロスオリジンで`/mcp`とディスカバリードキュメントにアクセスできます。JSONボディの上限は25 MBで、15 MBのbase64ファイル入力に十分な大きさです。

***

## トラブルシューティング

> [accordion] エージェントがツールを呼び出すと403またはmissing\_scopeが返る
>
> その組織におけるあなたの**役割**に、ツールが必要とする権限がありません (例: `READER`が書き込みを試みた場合)。必要な権限は`missing_scope`エラーに示されます。すべてのツールが失敗する場合は、再接続するか*Log in with Didit*をやり直してください。(MCPはBearer/OAuthのみに対応しており、`x-api-key`はすべてのツールで拒否されるため、APIキーでは403は解決しません。)

> [accordion] 書き込みや削除が実行されなかった
>
> 破壊的なツールは、クライアントでの確認が必要です。呼び出しを承認するか、ツールの確認プロンプトが自動的に拒否されていないか確認してください。`didit_session_delete`、`didit_session_batch_delete`、`didit_org_reveal_application_api_key`は、さらにツールの引数に`confirm: true`が必要です。指定しない場合、何も実行される前に呼び出しが拒否されます。

> [accordion] 「organization\_id is required」と表示される、または結果が返らない
>
> 複数のアプリケーションを持っている可能性があります。`*_search`ツール (すべてを横断して検索します) を使うか、`didit_context_get`を実行して目的の`organization_id` / `application_id`を渡してください。

> [accordion] サインイン用のブラウザが開かない (ホスト型)
>
> 一部のクライアント (Windsurf、Zed) は`mcp-remote`ブリッジ経由で接続します。設定に`npx -y mcp-remote@latest https://mcp.didit.me/mcp`が含まれていることを確認してください。クライアントを開き直すと、OAuthハンドシェイクが再度トリガーされます。

> [accordion] クライアントにツールが表示されない
>
> サーバーが接続されていること (ほとんどのクライアントはステータスドットを表示します) と、*Log in with Didit*を完了したことを確認してください。設定を編集した後は、MCPホストを再起動してください。`didit_org_top_up`と`didit_org_reveal_application_api_key`は、ホスト型コネクタには一切表示されません。

> [accordion] VS Code (または他のクライアント) がOAuthを検出できない、またはブラウザが開かない
>
> オリジンのみの`https://mcp.didit.me`ではなく、`https://mcp.didit.me/mcp`を指定していることを確認してください。リソースメタデータはそのパスにスコープされた`/.well-known/oauth-protected-resource/mcp`で提供されます (オリジンのルートを確認するクライアント向けに、ルートにもコピーがあります)。セルフホストしている場合、通常は`MCP_RESOURCE_URI`に完全なトランスポートURLではなくオリジンが設定されていることが原因です。[セルフホスティング](#セルフホスティング)を参照してください。

> [accordion] ファイルのアップロードが拒否される
>
> ホスト型エンドポイントに対しては、ファイルを`*_base64` (生のbase64または`data:` URL) として送信してください。`*_path`はローカルのstdioサーバーでのみ機能します。ファイルの上限は15 MBで、拡張子だけでなく内容がPNG、JPG、WebP、GIF、BMP、ICO、PDFのいずれかである必要があります。

***

## セキュリティ

MCPはあなたの実際の権限で動作し、本番のリソースを変更できます。クライアントでは**「実行前にツール呼び出しを確認する」**設定を有効のままにしてください。特に**書き込み**と**Destructive**のツールでは必須です。MCP自体は設定に**シークレットを一切保存せず**(**Didit でログイン**を使用します)、ツールの出力に含まれるAPIキーとWebhookの署名シークレットを伏せ字にし、チャージ用ツールと生のキーを扱うツールをホスト型カタログから除外し、リモートサーバー上ではアカウントの認証情報をツールの引数として受け付けません。すべてのツール呼び出しは、呼び出し元、ツール、権限の判定結果とともにサーバーの監査ログに記録されます。

### プロンプトインジェクション

Diditのツールは、氏名、書類のテキスト、アンケートの回答など、ユーザーが入力またはアップロードした内容を返します。
これらのテキストは認証を受ける本人が自由に書けるため、本人が氏名や書類にエージェント向けの指示を書き込むことができます。サーバーはこれらのフィールドを取得したときのまま返します。
エージェントはこうしたテキストとあなた自身の指示を確実に見分けることができないため、すべてのツールの結果はデータとして扱ってください。

* **書き込み**と**Destructive**のツールではツールの承認を有効のままにし、承認する前にエージェントが実行しようとしている内容を確認してください。
* 作業内容に見合った役割のメンバーとしてサインインしてください。セッションを読み取るだけのエージェントであれば`READER`メンバーを使えます。その場合、エージェントが何を試みてもバックエンドが書き込みを拒否します。
* 新しいエージェントやプロンプトは、まず[サンドボックスのアプリケーション](https://docs.didit.me/ja/integration/sandbox-testing.md)で試してください。
* 認証の中に含まれるテキストがそう指示しているという理由で、その認証を承認または却下しないでください。判定、その警告、そしてあなた自身のレビューに基づいて判断してください。

### 個人データ

ツールの結果には、氏名、生年月日、書類番号、画像へのリンクなどの個人データが含まれることがあり、MCPクライアントはそれらを使用中のモデルに送信します。
本番のアプリケーションを接続する前に、AIプロバイダーとの契約がこのデータを対象としていることを確認するか、サンドボックスのアプリケーションで作業してください。

***

## セルフホスティング

ホスト型サーバーは[github.com/didit-protocol/mcp](https://github.com/didit-protocol/mcp)(MIT)からビルドされています。リポジトリをクローンし、**Docker**またはNodeで実行してください。どちらのトランスポートでも、常にDiditの**ユーザー**として認証します(APIキーモードはありません)。セットアップ手順は[インストール → セルフホスティング](https://docs.didit.me/ja/integration/mcp/installation.md#セルフホスティング)にあります。

```bash theme={null}
git clone https://github.com/didit-protocol/mcp.git && cd mcp

# Docker (recommended) — serves /mcp + /healthz on port 3000
docker build -t didit-mcp . && docker run -p 3000:3000 --env-file .env didit-mcp

# …or with Node
npm install && npm run build
node dist/http.js                                          # hosted HTTP/OAuth
DIDIT_ACCESS_TOKEN=<user-access-token> node dist/index.js  # stdio (headless)
```

### 環境変数

| 変数 | モード | 用途 |
| - | - | - |
| `DIDIT_ACCESS_TOKEN` | stdio | ヘッドレス実行用の、ユーザーのBearerアクセストークン。 |
| `DIDIT_API_BASE_URL` | 両方 | Verification APIのベースURL(デフォルトは`https://verification.didit.me/v3`)。 |
| `DIDIT_AUTH_BASE_URL` | 両方 | Auth APIのベースURL(デフォルトは`https://apx.didit.me/auth/v2`)。 |
| `MCP_PORT` | ホスト型 | HTTPの待ち受けポート(デフォルトは`3000`)。 |
| `MCP_RESOURCE_URI` | ホスト型 | パスを含むトランスポートの公開URL(例: `https://mcp.example.com/mcp`)。RFC 9728のメタデータURLはここから導出されます。 |
| `MCP_AUTHORIZATION_SERVER_ORIGIN` | ホスト型 | 認可サーバーのオリジン(デフォルトは`https://business.didit.me`)。 |
| `MCP_TOKEN_VERIFY_MODE` | ホスト型 | `introspection`(デフォルト、不透明トークン)または`jwks`(JWTアクセストークン)。 |
| `MCP_OAUTH_INTROSPECT_URL` | ホスト型 | RFC 7662のイントロスペクションエンドポイント。 |
| `MCP_OAUTH_CLIENT_ID` / `MCP_OAUTH_CLIENT_SECRET` | ホスト型 | リソースサーバーがイントロスペクションを呼び出す際に使うBasic認証の認証情報。シークレットマネージャーから渡してください。 |
| `MCP_SCOPES_SUPPORTED` | ホスト型 | メタデータで公開するスコープ(デフォルトは`didit:management didit:verification`)。 |
| `MCP_DEFAULT_ORG` / `MCP_DEFAULT_APP` | 両方 | シングルテナント構成でスコープを自動入力します。 |
| `DIDIT_AUTH_ISSUER`, `DIDIT_OIDC_DISCOVERY_URL`, `DIDIT_OIDC_AUTHORIZE_URL`, `DIDIT_OIDC_TOKEN_URL`, `DIDIT_OIDC_REGISTRATION_URL` | ホスト型 | 認可サーバーのメタデータを上書きします。認可サーバーがオリジンのデフォルト以外の場所でエンドポイントを公開している場合にのみ必要です。 |
| `DIDIT_JWKS_URL` | ホスト型 | `MCP_TOKEN_VERIFY_MODE=jwks`のときに使用するJWKS。 |
| `MCP_PERMISSION_MODE` | 両方 | ツールごとの権限の事前チェック: `shadow`(デフォルト)、`enforce`または`off`。 |
| `MCP_JSON_BODY_LIMIT` | ホスト型 | JSON-RPCのボディサイズの上限(デフォルトは`25mb`)。 |

リポジトリ内の`.env.example`はコピーして使えるテンプレートで、`ARCHITECTURE.md`ではリソースサーバーと認可サーバーの役割分担を説明しています。HTTPサーバーは起動時に認可サーバーのディスカバリードキュメントを取得し、到達できない場合は設定済みのURLにフォールバックします。

***

> [card] [ツールリファレンス](https://docs.didit.me/ja/integration/mcp/tools.md)
>
> すべてのツールを分野別にまとめています。

> [card] [使用例](https://docs.didit.me/ja/integration/mcp/examples.md)
>
> プロンプトとエンドツーエンドの会話例。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.