MCP Form- vs. URL-Elicitation: Nutzerdaten sicher abfragen

Nutzen Sie den Form-Modus für eine kleine Menge nicht geheimer strukturierter Antworten, die der Nutzer im MCP-Client prüfen und senden kann: Umgebungsname, Berichtsformat, Datumsbereich oder Parameterbestätigung. Der URL-Modus ist erforderlich, wenn die Interaktion Passwort, API-Key, Access Token, Zahlungsdaten oder Third-Party-Autorisierung enthält. Diese Werte werden außerhalb des Clients eingegeben und nicht im ElicitResult-Content zurückgegeben.

Elicitation ist keine Erlaubnis für das Modell zu handeln und ersetzt keine Autorisierung. Sie gibt dem Server nur einen kontrollierten Weg, während eines auslösenden Requests die Mitwirkung des Nutzers anzufordern. Nach der Antwort prüft der Server erneut Identität, Scope, Business Policy und den aktuellen Objektzustand. Ist ein Wert bereits aus einem autoritativen System bekannt oder für die Ausführung unnötig, sollte keine Elicitation erfolgen: Jeder zusätzliche Prompt erhöht Friction und Phishing-Angriffsfläche.

• Nicht geheime primitive Felder → Form-Modus.
• Credentials, Payment oder externes OAuth → URL-Modus.
• Freigabe einer folgenreichen Aktion → separater Policy-/Approval-Gate statt beliebigem Formularfeld.
• Client kündigt den benötigten Modus nicht an → kontrollierter Fallback oder Ablehnung.
• Autoritativer Wert existiert bereits → aus dem System of Record lesen.

Der Client kündigt während der Initialisierung seine Elicitation-Capability und die unterstützten Form- und/oder URL-Modi an. Ein leeres Elicitation-Objekt ist mit Form-only-Verhalten kompatibel; der Server darf daraus keine URL-Unterstützung ableiten. Speichern Sie das Session-Capability-Manifest zusammen mit ausgehandelter Protocol- und Implementation-Version und prüfen Sie vor elicitation/create den benötigten Modus. Ein Anwendungsname oder ein Button in einem Client beweist keine Kompatibilität in einem anderen Deployment.

Server-to-client Elicitation muss mit einem auslösenden Client-Request wie tools/call oder resources/read verbunden sein. Bauen Sie keinen unabhängigen Kanal für unerbetene Prompts. Der Router bestimmt die Voraussetzung vor jedem Side Effect: Form unterstützt, URL unterstützt, No-Elicitation-Fallback oder blockiert. Kann ein Workflow ohne URL-Modus kein Credential sicher erhalten, ist ein Setup-Link außerhalb des Workflows oder eine klare Ablehnung der richtige Fallback — nicht die Secret-Abfrage in einem Textfeld.

Ein Form-Request enthält eine verständliche Nachricht und ein eingeschränktes JSON Schema: ein flaches Objekt mit primitiven Properties. Diese Begrenzung ist sinnvoll, weil Elicitation eine kurze Interaktion bleibt statt zu einer versteckten Formularplattform zu werden. Namen, Beschreibungen, Defaults, Enum-Labels und Pflichtfelder müssen die Konsequenz der Antwort erklären. Fügen Sie keine klickbaren URLs in Formularfelder ein und fragen Sie keine Secrets ab, auch wenn das Schema technisch Strings akzeptiert.

Der Client lässt den Nutzer die Antwort prüfen, ändern, akzeptieren, ablehnen oder abbrechen und validiert den Content gegen das Schema. Der Server wiederholt Schema- und Domain-Validierung: Range, Tenant-Zugehörigkeit, Objektexistenz, aktuelle Version und erlaubte Transitions. Accept bedeutet, dass Werte gesendet wurden; es genehmigt keine spätere Hochrisikoaktion automatisch. Decline beendet den Request ohne versteckten Default, und Cancel darf nicht als negative Business-Entscheidung interpretiert werden.

• Nur Felder erfassen, die für den aktuellen Request nötig sind.
• Schema-Gültigkeit von Business-Autorisierung trennen.
• Vollständigen Content nicht ohne Retention-Zweck und Data Classification loggen.
• Nach Decline oder Cancel den Prompt nicht in einer endlosen Agent Loop wiederholen.

Ein URL-Request enthält Modus, Nachricht, eine opaque elicitationId und eine URL. Der Client zeigt die vollständige Adresse, hebt die Domain hervor, fragt nach ausdrücklicher Zustimmung, lädt keine Metadaten vor und öffnet den Flow in einem sicheren Browser-Kontext, in dem weder Client noch LLM die eingegebenen Daten sehen. Der Server legt keine PII, Credentials oder pre-authenticated Bearer Capability in die URL. HTTPS ist Production-Baseline; verdächtige Unicode- oder Punycode-Hosts erfordern Warning- oder Block-Policy.

ElicitResult accept im URL-Modus bedeutet nur Zustimmung zur Navigation. Es beweist nicht, dass OAuth, Payment oder Credential-Setup abgeschlossen sind. Der Server führt einen separaten State Record nach elicitationId, gebunden an den autoritativen Nutzer, Client-/Session-Kontext, vorgesehenen Provider, Ablaufzeit und einmalige Nonce. Completion bestätigt ein serverseitiger Callback oder ein anderes autoritatives System. Eine elicitation/complete-Notification kann den Client wecken; manueller Retry oder Cancel bleibt verfügbar, falls die Notification verloren geht.

MCP Authorization schützt den Zugriff des Clients auf den MCP Server. URL Elicitation löst ein anderes Problem: Der Server bittet den Nutzer, einen Downstream Service zu verbinden oder eine sichere Out-of-Band-Interaktion abzuschließen. Der Bearer Token zwischen Client und MCP Server ändert sich durch diesen Flow nicht. Geben Sie einen Downstream Token niemals über Model Context, Tool Result oder Form Content zurück; der Server speichert das Credential in einem verwalteten Vault und bindet es an verifizierte Identität und Scope.

Die Connect-URL muss Phishing Relay widerstehen. Der Server prüft, dass der Browser-Nutzer derselbe autoritative Subject ist, für den die Elicitation erstellt wurde, statt E-Mail oder Name aus einem Query Parameter zu vertrauen. State und Nonce sind einmalig, kurzlebig und an Provider sowie Redirect Target gebunden. Der Callback prüft Issuer, Audience, State und erlaubte Redirect URI. Erneutes Öffnen, Nutzerwechsel oder ein abgelaufener Record enden ohne Credential Attachment.

• MCP Token → Client-to-Server Access.
• Downstream Grant → Server-to-Third-Party Access für einen bestimmten Nutzer oder Tenant.
• elicitationId → Korrelations-Handle, kein Nachweis für Identität oder Completion.
• Browser Session + verifizierter Subject → autoritative Bindung.

Contract Tests decken Initialisierung mit Form-only, URL-only, beiden Modi und ohne Elicitation ab; omitted mode als Form; unsupported mode; Accept, Decline und Cancel; Schema-Rejection; unbekannte oder doppelte Completion IDs sowie Request Association. URL-Fälle prüfen, dass der Client die Adresse nicht vorlädt, den Host zeigt, Consent verlangt und keinen externen Content im Protocol Result zurückgibt. Form-Fälle blockieren Password-, Token-, API-Key- und Payment-Fixtures unabhängig vom Feldnamen.

Security Tests versuchen elicitationId, Tenant, Provider, Redirect, State und Browser Subject zu verändern, Callback zu wiederholen, abgelaufene URL zu nutzen, Punycode Host einzusetzen oder ein Secret aus Logs und Traces zu lesen. Recovery Tests verlieren Accept Response, Completion Notification und auslösenden Retry. Assertions verlangen idempotentes Resume: Ein wiederholter Tool Request reconciled zuerst Elicitation State und Downstream Connection statt einen zweiten OAuth Grant oder Payment zu erzeugen.

• Hard Gate → Secret im Formular, automatische Navigation, Identity Mismatch oder Credential Leakage.
• Protocol Gate → Request ohne Association oder Modus ohne Capability.
• Recovery Gate → verlorene Notification darf keinen doppelten externen Effekt erzeugen.
• UX Gate → Server, Zweck, Domain sowie Decline/Cancel sind vor Consent verständlich.

Starten Sie Form Mode für einen reversiblen Read-only-Workflow mit zwei oder drei nicht geheimen Feldern. Messen Sie Completion, Decline/Cancel, Validation Failures, wiederholte Prompts und Time-to-Resume, ohne Raw Values in allgemeine Telemetry zu schreiben. Fügen Sie danach einen URL-Flow zu einem allowlisted HTTPS Origin mit gepinnter Redirect Policy, verifizierter Identity Binding, Expiry, Replay Protection, Vault Storage, Audit Evidence und Kill Switch hinzu.

Promoten Sie den Canary erst nach erfolgreichen Contract-, Privacy-, Phishing-, Recovery- und Accessibility-Gates. Rollback blockiert neue Elicitation Requests, behält Reconciliation für In-flight Records, widerruft unvollständige State Handles und stellt einen dokumentierten manuellen Setup-Pfad wieder her. Retests sind nach Änderungen an MCP Revision, SDK/Client, Capability Manifest, Browser Container, Identity Provider, Downstream-OAuth-Konfiguration oder Data Classification nötig. Das Verdict gilt immer für eine konkrete Client-Server-Flow-Kombination, nicht für eine universelle Sicherheit des URL-Modus.