--- title: "MCP oder WebMCP: Wo ein Agent beim Kontakt stoppt" description: "Ein Agent kann Leistungen lesen und einen sichtbaren Kontaktentwurf ausfüllen. Diese Website trennt Vorbereitung, Zustimmung, Serverprüfung und Versand und benennt die Grenzen erneuter Versuche." canonical: https://arnekellmann.de/de/blog/mcp-webmcp-kontaktentwurf published: 2026-10-12 modified: 2026-10-12 lang: de --- # MCP oder WebMCP: Wo ein Agent beim Kontakt stoppt Ein Assistent kann dabei helfen, ein Architekturproblem zu beschreiben, die passende Leistung zu finden und eine brauchbare Anfrage vorzubereiten. Beim Kontaktformular braucht es trotzdem eine klare Übergabe. Auf dieser Website soll der Assistent einen sichtbaren Entwurf hinterlassen, den die Person vor dem Absenden prüft. Diese Entscheidung trennt drei Vorgänge, die leicht wie ein einziger klingen: Informationen lesen, ein Formular verändern und einen Server zum Versand einer Nachricht auffordern. MCP und WebMCP können diese Vorgänge leichter auffindbar machen. Keiner der beiden Namen erteilt die Berechtigung für alle drei. ## Die Schnittstelle nach dem Vorgang wählen Der [Agentenleitfaden der Website](https://arnekellmann.de/agents.md) beginnt mit öffentlichen Leistungsinformationen und Dokumentation. Eine anonyme Abfrage des MCP-Werkzeugkatalogs am 12. Oktober 2026 lieferte vier Werkzeuge: `list_services`, `read_document`, `search_docs` und `search_mentions`. Alle waren als schreibgeschützt gekennzeichnet. Ein anonymer Aufruf von `read_document` lieferte außerdem die Entwicklerdokumentation. Diese Prüfungen belegten den Zugriff auf diese Lesevorgänge; sie prüften keinen Nachrichtenversand. Diese Schnittstelle passt, wenn der Assistent vor dem Schreiben Kontext braucht. Er kann die Angaben der Website lesen, ohne das Kontaktformular zu öffnen. MCP selbst kann mehr als lesen: Die [Serverdokumentation](https://modelcontextprotocol.io/docs/learn/server-concepts) beschreibt Werkzeuge, die APIs aufrufen und Zustände verändern können. Entscheidend ist hier der Werkzeugkatalog dieses Servers. Ein anderer MCP-Server könnte eine Versandaktion anbieten. WebMCP betrifft einen anderen Ablauf: Ein Agent arbeitet mit einer bereits im Browser geöffneten Seite. Chromes [aktuelle Übersicht](https://developer.chrome.com/docs/ai/webmcp) beschreibt einen vorgeschlagenen Standard für Seitenwerkzeuge, darunter Formularinteraktionen. Er kann sich noch ändern. Prüfe Browserunterstützung und registrierte Werkzeuge der Website getrennt; das normale Formular setzt keine verfügbare Agentenschnittstelle voraus. Der am 12. Oktober geprüfte Browsercode dieser Website registriert `stage_contact_enquiry`, wenn das Kontaktformular vorhanden und die benötigte WebMCP-API verfügbar ist. Das Werkzeug nimmt Name, E-Mail-Adresse, Betreff und Nachricht entgegen. Es füllt diese sichtbaren Felder und liefert einen Entwurfsstatus mit `submitted: false`. Es enthält keinen Aufruf zum Absenden und setzt weder die Datenschutzzustimmung noch ein Turnstile-Token. Diese Quellcodeprüfung umfasst den registrierten Code; sie deckt nicht jeden Browser oder Agenten ab. ## Die Übergabe sichtbar machen Ein hypothetischer Auftrag lautet: „Hilf mir zu fragen, ob eine Architekturbewertung zu unserem Retrieval-Dienst passt.“ Der Assistent kann die Leistungsbeschreibung lesen, fehlenden Kontext erfragen und eine abgestimmte Nachricht ins Formular eintragen. Die Person kann anschließend genau prüfen, welche Adresse und welcher Text übermittelt würden. 
Öffentliche Informationen
        ↓
Sichtbarer Kontaktentwurf
        ↓
Person prüft und sendet ab
        ↓
Server prüft die Anfrage
        ↓
Anbieter nimmt an oder lehnt ab
Vorgesehener Ablauf dieser Website. Die Grafik beschreibt die Übergabe, keinen aufgezeichneten Nachrichtenversand.
Das Ergebnis muss als Entwurf erkennbar bleiben. In der Antwort des Assistenten darf daraus kein „Nachricht gesendet“ werden. Das [Kontaktformular der Website](https://arnekellmann.de/de/contact) bietet die separate Oberfläche zum Prüfen und Absenden. Es gibt einen praktischen Grund, die Zustimmung nicht als Eingabe des Entwurfswerkzeugs anzubieten. Eine Person kann die Formulierung akzeptieren, aber den Zweck ablehnen oder bemerken, dass sie bestimmte Informationen nicht offenlegen möchte. Das Ausfüllen des Textes soll diese Entscheidung offenlassen. Das Werkzeug mit seinen vier Feldern behandelt auch das aktuelle Verifizierungstoken des Browsers nicht als etwas, das der Assistent erfinden oder wiederverwenden soll. Dieses begrenzte Werkzeug ist keine Sandbox für jeden Browseragenten. Ein Agent mit zusätzlichen Klick- oder HTTP-Fähigkeiten kann den normalen Versandweg versuchen. Der Werkzeugvertrag legt fest, was dieses Werkzeug tut; er beweist nicht, dass ausschließlich ein Mensch den Absenden-Button erreichen kann. Ein weitergehender Agentenablauf braucht weiterhin eine ausdrückliche Autorisierungsgrenze. ## Die Serverprüfungen getrennt halten Die Prüfung der Kontaktroute und ihres Schemas am 12. Oktober zeigte einen eigenen Versandweg über `POST /api/contact`. Das Schema verlangt `gdprConsent: true`. Die Route blockiert fehlende Turnstile-Konfiguration, ein fehlendes Token oder eine erfolglose Verifizierung, bevor sie den E-Mail-Anbieter aufruft. Das sind geprüfte Implementierungsbedingungen. Die Artikelprüfungen umfassten keinen erfolgreichen Kontaktversand in Produktion. Der Server erhält einen Zustimmungswert. Daraus kann er nicht ableiten, wer das Kästchen angekreuzt hat oder ob die Person die Offenlegung verstanden hat. Das Pflichtfeld und eine sichtbare Zustimmungsmöglichkeit sind nützliche Bestandteile des Ablaufs. Sie sind kein technischer Beweis informierter Zustimmung und keine rechtliche Konformitätsprüfung. Turnstile beantwortet eine andere Frage. Cloudflares [Dokumentation zur Serververifizierung](https://developers.cloudflare.com/turnstile/get-started/server-side-validation/) verlangt, dass das Backend das Token über Siteverify prüft. Laut Dokumentation laufen diese Tokens nach fünf Minuten ab und lassen sich einmal validieren. Ein Token aus einem alten Entwurf ist deshalb keine dauerhafte Versandberechtigung. Eine erfolgreiche Verifizierung belegt weder informierte Zustimmung noch die Identität des Absenders oder den Empfang der Nachricht. Die öffentliche Entwicklerdokumentation der Website spricht derzeit von „Turnstile when configured“. Die geprüfte Route ist strenger: Fehlt die Konfiguration, blockiert sie den Versand. Dieser Unterschied ist bei der Bewertung der Implementierung relevant; die Formulierung der Dokumentation allein belegt nicht das Fehlerverhalten des Servers. ## Den tatsächlich erreichten Zustand melden Ein ausgefülltes Formular belegt die Vorbereitung. Eine erfolgreiche Antwort des E-Mail-Anbieters belegt unter dem geprüften Versandweg die Annahme durch den Anbieter. Sie belegt nicht, dass der Empfänger die Nachricht erhalten oder gelesen hat. Nach einer fehlgeschlagenen oder unterbrochenen Anfrage kann der Versandstatus unklar bleiben. Der Assistent darf daraus weder eine Erfolgsmeldung noch automatisch eine zweite Nachricht machen. Der [Entwicklerleitfaden](https://arnekellmann.de/de/developers) dokumentiert einen optionalen Idempotenzschlüssel für API-Anfragen. [Resend bewahrt diese Schlüssel 24 Stunden auf](https://resend.com/docs/dashboard/emails/idempotency-keys), damit eine wiederholte identische Versandanfrage keine weitere E-Mail auslöst. Ein erneuter Versuch benötigt den ursprünglichen Schlüssel, identische Felder und eine frische gültige Verifizierung. Das geprüfte normale Browserformular ergänzt diesen Schlüssel nicht. Sein Timeout rechtfertigt daher keine stille Wiederholung der Anfrage. Für ein Team, das eine Integration auswählt, ist die sinnvolle Prüfung konkret: Kann der Assistent den nötigen öffentlichen Kontext lesen, kann die Person den Entwurf prüfen, und erzwingt der Server seine eigenen Versandbedingungen? Hier bietet MCP öffentliche Lesezugriffe und WebMCP einen begrenzten Formularvorgang. Getrennte Ergebnisse lassen den Assistenten bei der Anfrage helfen und erhalten eine sichtbare, prüfbare Entscheidung vor dem Versand.