Elicitation

Documentation Index

完全なドキュメント索引を取得してください: modelcontextprotocol.io/llms.txt

さらに先へ進む前に、利用可能なすべてのページを把握するために、このファイルを使用してください。

The Model Context Protocol (MCP) は、やり取りの途中で server が client を通じてユーザーに追加情報を要求するための標準化された方法を提供します。このフローにより、ユーザーとのやり取りやデータ共有について client が制御を維持しつつ、server は必要な情報を動的に収集できます。

Elicitation は 2 つのモードをサポートします。

Form mode: server は、レスポンスを検証するための任意の JSON Schema とともに、構造化データをユーザーに要求できる
URL mode: server は、MCP client を通過してはならない機密性の高いやり取りのために、ユーザーを外部 URL へ誘導できる

User Interaction Model

MCP における Elicitation により、server は、ほかの MCP server feature の内側にネストされた形でユーザー入力要求を発生させることで、対話的なワークフローを実装できます。

実装は、自身の要件に合う任意のインターフェイスパターンで elicitation を公開して構いません。プロトコル自体は、特定のユーザーインタラクションモデルを義務付けていません。

trust & safety および security のために:

server は、password、API key、Access Token、支払い認証情報などの機密情報を要求するために form mode elicitation を使用してはならない

そのような機密情報を伴うやり取りには、server は URL mode を使用しなければならない

この文脈での「機密情報」とは、アクセスを付与したり取引を認可したりする secret や credential を指します。名前、メールアドレス、username といった一般的な連絡先情報やプロフィール情報は、カテゴリとして一律に禁止されるわけではありません。そのようなデータを form mode で要求するかどうかは、server の裁量と、ユーザーが確認して拒否できるかどうかに委ねられます。

MCP client は次を満たさなければなりません (MUST)。

どの server が情報を要求しているのかが明確に分かる UI を提供する

ユーザーのプライバシーを尊重し、明確な decline および cancel の選択肢を提供する

form mode では、送信前にユーザーが回答を確認し、修正できるようにする

URL mode では、対象の domain/host を明確に表示し、対象 URL へ移動する前にユーザーの同意を取得する

Capabilities

elicitation をサポートする client は、初期化時に elicitation capability を宣言しなければなりません (MUST)。

{
  "capabilities": {
    "elicitation": {
      "form": {},
      "url": {}
    }
  }
}

後方互換性のため、空の capabilities object は form mode のみのサポートを宣言したものと等価です。

{
  "capabilities": {
    "elicitation": {}, // Equivalent to { "form": {} }
  },
}

elicitation capability を宣言する client は、少なくとも 1 つの mode（form または url）をサポートしなければなりません (MUST)。

server は、client がサポートしていない mode を使った elicitation request を送信してはなりません (MUST NOT)。

Protocol Messages

Elicitation Requests

ユーザーに情報を要求するために、server は elicitation/create request を送信します。

すべての elicitation request は、次のパラメータを含まなければなりません (MUST)。

Name	Type	Options	Description
`mode`	string	`form`, `url`	elicitation の mode。form mode では省略可能（省略時は `"form"` がデフォルト）。
`message`	string		なぜこのやり取りが必要なのかを説明する、人が読めるメッセージ。

mode パラメータは、elicitation の種類を指定します。

"form": 帯域内での構造化データ収集。任意で schema 検証を伴う。データは client に公開される
"url": URL 遷移による帯域外のやり取り。URL 自体を除くデータは client に公開されない

後方互換性のため、server は form mode elicitation request において mode フィールドを省略しても構いません (MAY)。client は、mode フィールドのない request を form mode として扱わなければなりません (MUST)。

Form Mode Elicitation Requests

form mode elicitation により、server は MCP client を通じて構造化データを直接収集できます。

form mode elicitation request は、mode: "form" を指定するか mode フィールドを省略し、さらに次のパラメータを含まなければなりません (MUST)。

Name	Type	Description
`requestedSchema`	object	想定されるレスポンスの構造を定義する JSON Schema。

Requested Schema

requestedSchema パラメータにより、server は制限された JSON Schema のサブセットを使って、期待するレスポンスの構造を定義できます。

client のユーザー体験を単純にするため、form mode elicitation schema は、primitive な property のみを持つフラットな object に制限されています。

schema は、次の primitive type に制限されます。

String Schema

{
  "type": "string",
  "title": "Display Name",
  "description": "Description text",
  "minLength": 3,
  "maxLength": 50,
  "pattern": "^[A-Za-z]+$",
  "format": "email",
  "default": "user@example.com"
}

サポートされる format: email, uri, date, date-time

Number Schema

{
  "type": "number", // or "integer"
  "title": "Display Name",
  "description": "Description text",
  "minimum": 0,
  "maximum": 100,
  "default": 50
}

Boolean Schema

{
  "type": "boolean",
  "title": "Display Name",
  "description": "Description text",
  "default": false
}

Enum Schema

タイトルなし単一選択 enum:

{
  "type": "string",
  "title": "Color Selection",
  "description": "Choose your favorite color",
  "enum": ["Red", "Green", "Blue"],
  "default": "Red"
}

タイトルあり単一選択 enum:

{
  "type": "string",
  "title": "Color Selection",
  "description": "Choose your favorite color",
  "oneOf": [
    { "const": "#FF0000", "title": "Red" },
    { "const": "#00FF00", "title": "Green" },
    { "const": "#0000FF", "title": "Blue" }
  ],
  "default": "#FF0000"
}

タイトルなし複数選択 enum:

{
  "type": "array",
  "title": "Color Selection",
  "description": "Choose your favorite colors",
  "minItems": 1,
  "maxItems": 2,
  "items": {
    "type": "string",
    "enum": ["Red", "Green", "Blue"]
  },
  "default": ["Red", "Green"]
}

タイトルあり複数選択 enum:

{
  "type": "array",
  "title": "Color Selection",
  "description": "Choose your favorite colors",
  "minItems": 1,
  "maxItems": 2,
  "items": {
    "anyOf": [
      { "const": "#FF0000", "title": "Red" },
      { "const": "#00FF00", "title": "Green" },
      { "const": "#0000FF", "title": "Blue" }
    ]
  },
  "default": ["#FF0000", "#00FF00"]
}

client はこの schema を使って次を行えます。

適切な入力フォームを生成する
送信前にユーザー入力を検証する
ユーザーにより良いガイダンスを提供する

すべての primitive type は、妥当な初期値を提供するための任意の default value をサポートします。default をサポートする client は、これらの値でフォームフィールドを事前入力すべきです (SHOULD)。

複雑なネスト構造、object の配列（enum を除く）、およびその他の高度な JSON Schema 機能は、client のユーザー体験を単純化するため、意図的にサポートされていない点に注意してください。

Example: Simple Text Request

Request:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "elicitation/create",
  "params": {
    "mode": "form",
    "message": "Please provide your GitHub username",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string"
        }
      },
      "required": ["name"]
    }
  }
}

Response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "action": "accept",
    "content": {
      "name": "octocat"
    }
  }
}

Example: Structured Data Request

Request:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "elicitation/create",
  "params": {
    "mode": "form",
    "message": "Please provide your contact information",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string",
          "description": "Your full name"
        },
        "email": {
          "type": "string",
          "format": "email",
          "description": "Your email address"
        },
        "age": {
          "type": "number",
          "minimum": 18,
          "description": "Your age"
        }
      },
      "required": ["name", "email"]
    }
  }
}

Response:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "action": "accept",
    "content": {
      "name": "Monalisa Octocat",
      "email": "octocat@github.com",
      "age": 30
    }
  }
}

URL Mode Elicitation Requests

New feature: URL mode elicitation は、MCP specification の 2025-11-25 版で導入された新機能です。今後のプロトコル改訂で、その設計や実装が変更される可能性があります。

URL mode elicitation により、server は、MCP client を通過してはならない帯域外のやり取りのために、ユーザーを外部 URL へ誘導できます。これは、認可フロー、支払い処理、その他の機密または安全性が重要な操作にとって不可欠です。

URL mode elicitation request は、mode: "url" と message を指定し、さらに次のパラメータを含まなければなりません (MUST)。

Name	Type	Description
`url`	string	ユーザーが移動すべき URL。
`elicitationId`	string	elicitation の一意な識別子。

url パラメータには、有効な URL が含まれていなければなりません (MUST)。

Important: URL mode elicitation は、MCP client に MCP server へのアクセスを認可させるためのものではありません（それは MCP authorization で扱われます）。代わりに、MCP server がユーザーに代わって機密情報や third-party の認可を取得する必要がある場合に使用されます。MCP client の bearer token は変化しません。client の唯一の責務は、server が開かせようとしている elicitation URL について、ユーザーに文脈情報を提供することです。

Example: Request Sensitive Data

この例では、ユーザーが機密情報（たとえば API key）を提供できる安全な URL へ誘導する、URL mode elicitation request を示しています。同じ request で、OAuth の認可フローや支払いフローへユーザーを誘導することもできます。違うのは URL と message だけです。

Request:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "elicitation/create",
  "params": {
    "mode": "url",
    "elicitationId": "550e8400-e29b-41d4-a716-446655440000",
    "url": "https://mcp.example.com/ui/set_api_key",
    "message": "Please provide your API key to continue."
  }
}

Response:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "action": "accept"
  }
}

action: "accept" を含む response は、ユーザーがそのやり取りに同意したことを示します。これは、そのやり取りが完了したことを意味するものではありません。やり取りは帯域外で行われ、server が完了を示す notification を送らない限り、client はその結果を認識しません。

Completion Notifications for URL Mode Elicitation

server は、URL mode elicitation によって開始された帯域外のやり取りが完了したときに、notifications/elicitation/complete notification を送信しても構いません (MAY)。これにより、適切であれば client はプログラム的に反応できます。

notification を送信する server は次を満たさなければなりません (MUST)。

notification は、その elicitation request を開始した client にのみ送信しなければならない
元の elicitation/create request で確立した elicitationId を含めなければならない

client は次を満たします。

未知の ID、またはすでに完了済みの ID を参照する notification は無視しなければならない
この notification を待って、URLElicitationRequiredError を受けた request を自動で再試行したり、ユーザーインターフェイスを更新したり、あるいはその他の方法でやり取りを継続してもよい
notification が届かない場合でも、ユーザーが元の request を再試行または cancel できる手動コントロール（または client とのやり取りを再開できる何らかの手段）を提供すべきである (SHOULD)

Example

{
  "jsonrpc": "2.0",
  "method": "notifications/elicitation/complete",
  "params": {
    "elicitationId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

URL Elicitation Required Error

ある request を処理するために elicitation の完了が必要な場合、server は、client に URL mode elicitation が必要であることを示すために URLElicitationRequiredError（コード -32042）を返しても構いません (MAY)。URL mode elicitation が必要な場合を除いて、server はこの error を返してはなりません (MUST NOT)。

この error には、元の request を再試行する前に完了しなければならない elicitation の一覧を含めなければなりません (MUST)。

error 内で返される elicitation は、すべて URL mode elicitation であり、elicitationId property を持たなければなりません (MUST)。

Error Response:

{
  "jsonrpc": "2.0",
  "id": 2,
  "error": {
    "code": -32042, // URL_ELICITATION_REQUIRED
    "message": "This request requires more information.",
    "data": {
      "elicitations": [
        {
          "mode": "url",
          "elicitationId": "550e8400-e29b-41d4-a716-446655440000",
          "url": "https://mcp.example.com/connect?elicitationId=550e8400-e29b-41d4-a716-446655440000",
          "message": "Authorization is required to access your Example Co files."
        }
      ]
    }
  }
}

Message Flow

Form Mode Flow

sequenceDiagram participant User participant Client participant Server Note over Server: Server initiates elicitation Server->>Client: elicitation/create (mode: form) Note over User,Client: Present elicitation UI User-->>Client: Provide requested information Note over Server,Client: Complete request Client->>Server: Return user response Note over Server: Continue processing with new information

URL Mode Flow

sequenceDiagram participant UserAgent as User Agent (Browser) participant User participant Client participant Server Note over Server: Server initiates elicitation Server->>Client: elicitation/create (mode: url) Client->>User: Present consent to open URL User-->>Client: Provide consent Client->>UserAgent: Open URL Client->>Server: Accept response Note over User,UserAgent: User interaction UserAgent-->>Server: Interaction complete Server-->>Client: notifications/elicitation/complete (optional) Note over Server: Continue processing with new information

URL Mode With Elicitation Required Error Flow

sequenceDiagram participant UserAgent as User Agent (Browser) participant User participant Client participant Server Client->>Server: tools/call Note over Server: Server needs authorization Server->>Client: URLElicitationRequiredError Note over Client: Client notes the original request can be retried after elicitation Client->>User: Present consent to open URL User-->>Client: Provide consent Client->>UserAgent: Open URL Note over User,UserAgent: User interaction UserAgent-->>Server: Interaction complete Server-->>Client: notifications/elicitation/complete (optional) Client->>Server: Retry tools/call (optional)

Response Actions

elicitation response は、異なるユーザー操作を明確に区別するために、3 つの action モデルを使用します。これらの action は、form mode と URL elicitation mode の両方に適用されます。

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "action": "accept", // or "decline" or "cancel"
    "content": {
      "propertyName": "value",
      "anotherProperty": 42
    }
  }
}

3 つの response action は次のとおりです。

Accept (action: "accept"): ユーザーが明示的に承認し、データとともに送信した
- form mode では、content フィールドに、requested schema に一致する送信済みデータが含まれる
- URL mode では、content フィールドは省略される
- 例: ユーザーが "Submit"、"OK"、"Confirm" などをクリックした
Decline (action: "decline"): ユーザーが request を明示的に拒否した
- 通常、content フィールドは省略される
- 例: ユーザーが "Reject"、"Decline"、"No" などをクリックした
Cancel (action: "cancel"): ユーザーが明示的な選択をせずに閉じた
- 通常、content フィールドは省略される
- 例: ユーザーがダイアログを閉じた、外側をクリックした、Escape を押した、browser が読み込みに失敗した、など

server は各状態を適切に扱うべきです。

Accept: 送信されたデータを処理する
Decline: 明示的な拒否を扱う（たとえば代替手段を提示する）
Cancel: 閉じられた状態を扱う（たとえば後で再度促す）

Implementation Considerations

Statefulness

elicitation の実用的な利用の多くでは、server がユーザーに関する状態を維持する必要があります。

必要な情報が収集済みかどうか（たとえば form mode elicitation によるユーザーの display name）
resource access の状態（たとえば URL mode elicitation を通じた API key や payment flow）

elicitation を実装する server は、security best practices 文書のガイドラインに従って、この状態を個々のユーザーと安全に関連付けなければなりません (MUST)。特に次が必要です。

状態を session ID のみと結び付けてはならない
状態保存は不正アクセスから保護されていなければならない
remote MCP server では、可能であればユーザー識別は MCP authorization によって取得した credential から導出しなければならない（たとえば sub claim）

この節の例は規範的なものではなく、elicitation の潜在的な用途を示すものです。実装者は security best practices を維持しながら、自身の要件に合わせてこれらのパターンを調整すべきです。

URL Mode Elicitation for Sensitive Data

外部 API とやり取りし、そのために機密情報（たとえば credential、支払い情報）が必要な server にとって、URL mode elicitation は、その情報を MCP client にさらすことなくユーザーが提供するための安全な仕組みを提供します。

このパターンでは、次のように動作します。

server は、ユーザーを安全な web page（HTTPS で提供される）へ誘導する
その page は、ユーザーが信頼する domain 上で、ブランド化された form UI を提示する
ユーザーは、機密 credential を安全な form に直接入力する
server は、credential をユーザーの identity に結び付けて安全に保存する
以後の MCP request は、API access のためにこれらの保存済み credential を使用する

このアプローチにより、機密 credential が LLM context、MCP client、または中間の MCP server を一切通過しないことが保証され、client 側のログ記録やその他の攻撃ベクトルを通じた露出リスクを減らせます。

URL Mode Elicitation for OAuth Flows

URL mode elicitation により、MCP server が third-party Resource Server に対する OAuth client として振る舞うパターンが可能になります。 URL mode elicitation によって実現される外部 API との認可は、MCP authorization とは別物です。MCP server は、自身のためにユーザーを認可する目的で URL mode elicitation に依存してはなりません。

Understanding the Distinction

MCP Authorization: MCP client と MCP server の間で必要となる OAuth flow（authorization specification で扱われる）
External (third-party) Authorization: MCP server と third-party Resource Server の間の任意の認可であり、URL mode elicitation を通じて開始される

外部認可において、server は次の両方として振る舞います。

MCP client に対しては OAuth Resource Server
third-party Resource Server に対しては OAuth client

例となるシナリオ:

MCP client が MCP server に接続する
MCP server はさまざまな third-party service と統合している
MCP client が third-party service へのアクセスを必要とする tool を呼び出したとき、MCP server はその service 用の credential を必要とする

重要な security 要件は次のとおりです。

third-party credential は MCP client を通過してはならない: security boundary を守るため、client が third-party credential を見てはならない
MCP server は third-party service のために client の credential を使ってはならない: それは token passthrough であり、禁止されている
ユーザーは MCP server を直接認可しなければならない: やり取りは MCP client を介さず、MCP protocol の外側で行われる
MCP server が token に責任を持つ: URL mode elicitation で取得した third-party token の保存と管理は MCP server が担う（つまり、MCP server は stateful でなければならない）

URL mode elicitation で取得した credential は、MCP client が使用する MCP server credential とは別物です。MCP server は、URL mode elicitation で取得した credential を MCP client に送信してはなりません。

背景の詳細については、Security Best Practices 文書の token passthrough 節を参照してください。なぜ MCP server が pass-through proxy として振る舞えないのかを理解する助けになります。

Implementation Pattern

URL mode elicitation を通じて外部認可を実装する場合、次のようになります。

MCP server は third-party service に対する OAuth client として、authorization URL を生成する
MCP server は、elicitation request をユーザーの identity に関連付ける内部状態を保存する
MCP server は、認可フローを開始できる URL とともに URL mode elicitation request を client に送信する
ユーザーは、third-party Authorization Server と直接 OAuth flow を完了する
third-party Authorization Server は MCP server にリダイレクトバックする
MCP server は、third-party token をユーザーの identity に結び付けて安全に保存する
以後の MCP request は、third-party Resource Server への API access のために、これら保存済み token を利用できる

以下は、このパターンがどのように実装され得るかを示す非規範的な例です。

sequenceDiagram participant User participant UserAgent as User Agent (Browser) participant 3AS as 3rd Party AS participant 3RS as 3rd Party RS participant Client as MCP Client participant Server as MCP Server Client->>Server: tools/call Note over Server: Needs 3rd-party authorization for user Note over Server: Store state (bind the elicitation request to the user) Server->>Client: URLElicitationRequiredError<br> (mode: "url", url: "https://mcp.example.com/connect?...") Note over Client: Client notes the tools/call request can be retried later Client->>User: Present consent to open URL User->>Client: Provide consent Client->>UserAgent: Open URL Client->>Server: Accept response UserAgent->>Server: Load connect route Note over Server: Confirm: user is logged into MCP Server or MCP AS<br>Confirm: elicitation user matches session user Server->>UserAgent: Redirect to third-party authorization endpoint UserAgent->>3AS: Load authorize route Note over 3AS,User: User interaction (OAuth flow):<br>User consents to scoped MCP Server access 3AS->>UserAgent: redirect to MCP Server's redirect_uri UserAgent->>Server: load redirect_uri page Note over Server: Confirm: redirect_uri belongs to MCP Server Server->>3AS: Exchange authorization code for OAuth tokens 3AS->>Server: Grants tokens Note over Server: Bind tokens to MCP user identity Server-->>Client: notifications/elicitation/complete (optional) Client->>Server: Retry tools/call Note over Server: Retrieve token bound to user identity Server->>3RS: Call 3rd-party API

このパターンにより、third-party service と連携しつつ、明確な security boundary を維持できます。

Error Handling

server は、一般的な失敗ケースに対して標準の JSON-RPC error を返さなければなりません。

request を処理する前に elicitation の完了が必要な場合: -32042（URLElicitationRequiredError）

client は、一般的な失敗ケースに対して標準の JSON-RPC error を返さなければなりません。

client capability で宣言されていない mode を持つ elicitation/create request を server が送信した場合: -32602（Invalid params）

Security Considerations

server は、elicitation request を client とユーザー identity に結び付けなければならない
client は、どの server が情報を要求しているのかを明確に示さなければならない
client は、ユーザー承認のコントロールを実装すべきである
client は、ユーザーがいつでも elicitation request を decline できるようにすべきである
client は、rate limiting を実装すべきである
client は、何の情報が、なぜ要求されているのかが明確に分かる形で elicitation request を提示すべきである

Safe URL Handling

elicitation を要求する MCP server は次を守らなければなりません。

URL elicitation request で client に送る URL に、credential、個人識別情報など、end-user に関する機密情報を含めてはならない
保護された resource にアクセスするための事前認証済み URL を提供してはならない。その URL が悪意ある client によってユーザーになりすます目的で使われる可能性があるため
form mode elicitation request のどのフィールドにも、クリック可能にすることを意図した URL を含めるべきではない
開発環境以外では HTTPS URL を使うべきである

これらの server 要件により、client 実装は、どのような場合に URL をユーザーへ提示すべきかについて明確なルールを持つことができ、client 側のルールを一貫して適用できます。

URL mode elicitation を実装する client は、ユーザーが気付かずに悪意あるリンクをクリックしないよう、URL を慎重に扱わなければなりません。

URL mode elicitation request を扱う際、MCP client は次を守らなければなりません。

URL やその metadata を自動的に pre-fetch してはならない
ユーザーの明示的な同意なしに URL を開いてはならない
同意前に、確認のためユーザーへ URL 全体を表示しなければならない
client や LLM が内容やユーザー入力を検査できない、安全な方法で server が提供した URL を開かなければならない
たとえば iOS では SFSafariViewController は適しているが、WkWebView は適していない
subdomain spoofing を軽減するため、URL の domain を強調表示すべきである
曖昧または不審な URI（Punycode を含むなど）には警告を出すべきである
URL mode elicitation request の url フィールドを除き、elicitation request のいかなるフィールドでも URL を clickable として描画すべきではない（ただし url フィールドは、上記の制約に従う）

Identifying the User

server は、server による検証なしに client 提供のユーザー識別情報に依存してはなりません。これは偽装可能だからです。代わりに、server は security best practices に従うべきです (SHOULD)。

非規範的な例:

誤り: "I am joe@example.com" のようなユーザー入力を権威あるものとして扱う
正しい: authorization に依拠してユーザーを識別する

Form Mode Security

server は、機密情報（password、API key など）を form mode で要求してはならない
client は、提供された schema に対してすべての response を検証すべきである
server は、受信したデータが requested schema と一致することを検証すべきである

Phishing

URL mode elicitation は、攻撃者が被害者に送れる URL を返します。MCP Server は、情報を受け入れる前に、その URL を開いたユーザーの identity を検証しなければなりません (MUST)。

通常、identity の検証は、browser 内の session cookie などを通じてユーザーを識別するために MCP authorization server を活用して行われます。

たとえば、URL mode elicitation は、server が別の Resource Server の OAuth client として振る舞う OAuth flow を実行するために使われることがあります。適切な対策がなければ、次の phishing 攻撃が可能です。

悪意あるユーザー（Alice）が benign server に接続し、elicitation request を発生させる
benign server は、third-party Authorization Server の OAuth client として認可 URL を生成する
Alice の client は URL を表示し、同意を求める
Alice はそのリンクを自分でクリックせず、同じ benign server を使う被害者ユーザー（Bob）をだましてクリックさせる
Bob はリンクを開き、自分自身の benign server への接続を認可しているつもりで認可を完了する
benign server は third-party Authorization Server から callback/redirect を受け取り、それを Alice の request だと思い込む
その結果、third-party server の token が Bob ではなく Alice の session と identity に結び付けられ、アカウント乗っ取りが起きる

この攻撃を防ぐため、server は、elicitation request を開始したユーザー（MCP client を通じて server にアクセスしている end-user）と、認可フローを完了したユーザーが同一であることを保証しなければなりません (MUST)。

これを実現する方法はいくつもあり、最適な方法は実装によって異なります。

一般的な非規範的な例として、MCP server が web 経由でアクセス可能で、third-party の authorization code flow を実行したいケースを考えます。 phishing 攻撃を防ぐため、server は third-party authorization endpoint ではなく、https://mcp.example.com/connect?elicitationId=... に対する URL mode elicitation を作成します。この「connect URL」は、その page を開いたユーザーが、その URL mode elicitation を生成されたユーザーと同一であることを保証しなければなりません (MUST)。たとえば、ユーザーが有効な session cookie を持っていること、およびその session cookie が URL mode elicitation を生成した MCP client 利用者と同じユーザーのものであることを確認します。これは、MCP server の authorization server から得られる権威ある subject（sub claim）と、session cookie の subject を比較することで実現できます。その page が同一ユーザーであることを確認した後で、https://example.com/authorize?... にある third-party Authorization Server にユーザーを送れば、通常の OAuth flow を完了できます。

別のケースでは、server が web 経由でアクセスできず、session cookie を使ってユーザーを識別できないこともあります。その場合、server は、elicitation URL を開いたユーザーが、その URL mode elicitation を生成されたユーザーと同一であることを識別するための別の仕組みを使わなければなりません (MUST)。

すべての実装において、server は、ユーザー identity を判定する仕組みが、攻撃者による elicitation URL の改ざんに耐えられることを保証しなければなりません (MUST)。