MCP form vs URL elicitation: як безпечно запитувати дані користувача

Form mode використовуйте для невеликого набору несекретних структурованих відповідей, які користувач може переглянути й надіслати у MCP client: назва середовища, формат звіту, діапазон дат або підтвердження параметрів. URL mode потрібен, коли взаємодія містить пароль, API key, access token, платіжні реквізити або third-party authorization. Такі дані вводяться поза client і не повертаються в ElicitResult content.

Elicitation не є дозволом моделі діяти й не замінює authorization. Вона лише дає server контрольований спосіб попросити участь користувача під час originating request. Після відповіді server знову перевіряє identity, scope, business policy та актуальний стан об'єкта. Якщо дані вже відомі з authoritative system або питання не потрібне для виконання, не викликайте elicitation: зайвий prompt збільшує friction і phishing surface.

• Несекретні primitive fields → form mode.
• Credentials, payment або external OAuth → URL mode.
• Approval consequential action → окремий policy/approval gate, не довільне поле форми.
• Client не оголосив потрібний mode → контрольований fallback або відмова.
• Authoritative value уже доступне → прочитайте його з system of record.

Client оголошує elicitation capability під час initialization і підтримувані form та/або url modes. Порожній elicitation object сумісний із form-only поведінкою; server не повинен трактувати його як URL support. Зберігайте session capability manifest разом із negotiated protocol version та implementation version, а перед elicitation/create перевіряйте потрібний mode. Назва застосунку або наявність кнопки в одному client не доводить сумісність іншого deployment.

Server-to-client elicitation має бути пов'язана з originating client request, наприклад tools/call або resources/read. Не будуйте незалежний канал unsolicited prompts. Router визначає requirement до запуску side effect: form-supported, url-supported, no-elicitation fallback або blocked. Якщо workflow без URL mode не може безпечно отримати credential, правильний fallback — setup link поза workflow чи чітка відмова, а не запит secret через text field.

Form request містить human-readable message і restricted JSON Schema: flat object із primitive properties. Обмеження корисне — воно утримує elicitation як коротку взаємодію, а не приховану application form platform. Назви, descriptions, defaults, enum labels і required fields мають пояснювати наслідок відповіді. Не вставляйте clickable URL у поля форми й не просіть секрети навіть тоді, коли schema технічно приймає string.

Client дозволяє користувачу переглянути, змінити, accept, decline або cancel відповідь і валідовує content за schema. Server повторює schema та domain validation: range, tenant membership, object existence, current version і дозволені transitions. Accept означає, що користувач надіслав значення; це не автоматичне схвалення наступної високоризикової дії. Decline завершує запит без прихованого default, а cancel не слід інтерпретувати як негативну business decision.

• Збирайте лише поля, необхідні для поточного request.
• Відокремлюйте schema validity від business authorization.
• Не логайте повний content без retention purpose і data classification.
• Після decline/cancel не повторюйте prompt у нескінченному agent loop.

URL request містить mode, message, opaque elicitationId і URL. Client показує повну адресу та виділяє domain, питає explicit consent, не prefetch-ить metadata і відкриває flow у secure browser context, де client або LLM не бачить введені дані. Server не кладе PII, credentials чи pre-authenticated bearer capability у URL. HTTPS є production baseline; suspicious Unicode або Punycode host потребує warning чи block policy.

ElicitResult accept у URL mode означає лише згоду користувача перейти за адресою. Він не доводить, що OAuth, payment або credential setup завершено. Server зберігає окремий state record за elicitationId, прив'язаний до authoritative user, client/session context, intended provider, expiry та one-time nonce. Completion підтверджує server-side callback або інша система-власник; notification elicitation/complete може розбудити client, але manual retry/cancel лишається доступним, якщо notification загубилась.

MCP authorization захищає доступ client до MCP server. URL elicitation вирішує іншу задачу: server просить користувача підключити downstream service або виконати secure out-of-band interaction. Bearer token між client і MCP server через цей flow не змінюється. Не передавайте downstream token назад через model context, tool result чи form content; server зберігає credential у керованому vault і прив'язує його до перевіреної identity та scope.

Connect URL має протистояти phishing relay. Server перевіряє, що browser user є тією самою authoritative особою, для якої створено elicitation, а не довіряє email або ім'ю з query parameter. State/nonce одноразовий, короткоживучий і прив'язаний до provider та redirect target. Callback перевіряє issuer, audience, state і дозволені redirect URI. Повторне відкриття, зміна користувача або протермінований record завершуються без credential attachment.

• MCP token → client-to-server access.
• Downstream grant → server-to-third-party access для конкретного user/tenant.
• elicitationId → correlation handle, не доказ identity чи completion.
• Browser session + verified subject → authoritative binding.

Contract tests покривають initialization з form-only, url-only, обома modes і без elicitation; omitted mode як form; unsupported mode; accept, decline, cancel; schema rejection; unknown/duplicate completion ID та request association. URL cases перевіряють, що client не prefetch-ить адресу, показує host, вимагає consent і не повертає external content у protocol result. Form cases блокують password, token, API key і payment fixtures незалежно від їхньої назви.

Security tests намагаються змінити elicitationId, tenant, provider, redirect, state і browser subject; повторити callback; використати expired URL; підставити Punycode host; прочитати secret у logs або traces. Recovery tests гублять accept response, completion notification і originating retry. Assertions вимагають idempotent resume: повторний tool request спершу reconcile-ить elicitation state й downstream connection, а не створює другий OAuth grant або payment.

• Hard gate → secret у form, automatic navigation, identity mismatch або credential leakage.
• Protocol gate → request без association чи mode без capability.
• Recovery gate → lost notification не створює duplicate external effect.
• UX gate → server, purpose, domain і decline/cancel зрозумілі до consent.

Спочатку запустіть form mode для reversible read-only workflow з двома-трьома несекретними полями. Вимірюйте completion, decline/cancel, validation failures, repeated prompts і time-to-resume без запису raw values у загальну telemetry. Далі додайте один URL flow до allowlisted HTTPS origin із pinned redirect policy, verified identity binding, expiry, replay protection, vault storage, audit evidence та kill switch.

Canary просувають після contract, privacy, phishing, recovery й accessibility gates. Rollback блокує нові elicitation requests, залишає reconciliation для in-flight records, відкликає незавершені state handles і повертає documented manual setup path. Retest потрібен після зміни MCP revision, SDK/client, capability manifest, browser container, identity provider, downstream OAuth configuration або data classification. Verdict завжди стосується конкретної client-server-flow комбінації, а не універсальної безпеки URL mode.