--- title: "MCP or WebMCP: where a contact agent should stop" description: "An agent can read services and fill a visible contact draft. This website separates that preparation from consent, server verification and message delivery, with specific limits for retries." canonical: https://arnekellmann.de/blog/mcp-webmcp-contact-draft published: 2026-10-12 modified: 2026-10-12 lang: en --- # MCP or WebMCP: where a contact agent should stop An assistant can help someone describe an architecture problem, find the relevant service and prepare a useful enquiry. The contact message still needs a clear handoff. For this website, the intended stopping point is a visible draft that the person reviews before submitting. That choice separates three operations which can otherwise sound like one: reading information, changing a form and asking a server to send a message. MCP and WebMCP can make those operations easier to discover. Neither name establishes permission to perform all three. ## Choose the interface by the operation The website’s [agent guide](https://arnekellmann.de/agents.md) starts with public service information and documentation. An anonymous MCP inventory check on 12 October 2026 returned four tools: `list_services`, `read_document`, `search_docs` and `search_mentions`. All advertised read-only operation. An anonymous `read_document` call also returned the developer documentation. These checks established access to those reads; they did not exercise message delivery. That is a useful interface when the assistant needs context before drafting. It can read what the website says without opening the contact form. MCP itself supports more than reading: its [server documentation](https://modelcontextprotocol.io/docs/learn/server-concepts) describes tools that can call APIs and change state. This particular server’s inventory is the relevant limit. A different MCP server might expose a send action. WebMCP addresses a different setting: an agent working with the page already open in a browser. Chrome’s [current overview](https://developer.chrome.com/docs/ai/webmcp) describes it as a proposed standard for exposing page tools, including form interactions. It remains subject to change. Check browser support and the website’s registered tools separately; an ordinary form does not depend on the agent interface being available. This website’s inspected browser code registers `stage_contact_enquiry` when the contact form exists and the required WebMCP API is available. The tool accepts name, email, subject and message. It fills those visible fields and returns a draft result with `submitted: false`. It contains no submission call and does not set privacy consent or a Turnstile token. This source inspection on 12 October covers the registered code; it does not cover every browser or agent. ## Make the handoff visible Consider a hypothetical request: “Help me ask whether an architecture review fits our retrieval service.” The assistant can read the service description, ask for missing context and put an agreed message into the form. The person can then inspect exactly which address and text the form would send. 
Public information
        ↓
Visible contact draft
        ↓
Person reviews and submits
        ↓
Server validates the request
        ↓
Provider accepts or rejects
Intended workflow for this website. This diagram describes the handoff, not a recorded message delivery.
The draft result should remain visible as a draft. It must not become “message sent” in the assistant’s answer. The site’s [contact form](https://arnekellmann.de/contact) provides the separate review and submission surface. There is a practical reason to keep consent out of the staging inputs. A person may accept the proposed wording while rejecting its purpose, or decide that the message contains information they do not want to disclose. Filling the text should leave that decision open. The four-field tool also avoids treating a browser’s current verification token as something the assistant should manufacture or reuse. This narrow tool is not a sandbox for every browser agent. An agent with separate click or HTTP capabilities can attempt the ordinary submission path. The tool contract establishes what this tool does; it does not prove that only a human can ever reach the submit button. Any broader agent workflow still needs an explicit authorization boundary. ## Keep the server checks independent Inspection of the contact route and schema on 12 October found a separate `POST /api/contact` delivery path. The schema requires `gdprConsent` to be `true`. The route rejects missing Turnstile configuration, a missing token or unsuccessful verification before calling the email provider. Those are inspected implementation checks. The article checks included no successful production contact send. The server receives a consent boolean. It cannot infer from that value who checked the box or whether the person understood the disclosure. Requiring the field and providing a visible consent choice are useful parts of the workflow; they are not technical proof of informed consent or a legal compliance assessment. Turnstile answers another question. Cloudflare’s [server validation documentation](https://developers.cloudflare.com/turnstile/get-started/server-side-validation/) requires the backend to validate the token with Siteverify. The documented tokens expire after five minutes and can be validated once. A token copied from an old draft is therefore not a durable permission slip. Successful verification does not establish informed consent, the sender’s identity or recipient receipt. The website’s public developer documentation currently uses the phrase “Turnstile when configured.” The inspected route is stricter: missing configuration blocks delivery. That distinction matters when evaluating the implementation; documentation wording alone does not establish the server’s failure behavior. ## Report the state you actually reached A filled form establishes preparation. A successful response from the email provider establishes provider acceptance under the inspected send path. It does not establish that the recipient received or read the email. A failed or interrupted request may leave the delivery outcome uncertain; the assistant must not turn that uncertainty into either a success claim or an automatic second message. The [developer guide](https://arnekellmann.de/developers) documents an optional idempotency key for API submissions. [Resend retains these keys for 24 hours](https://resend.com/docs/dashboard/emails/idempotency-keys) to prevent repeated identical send requests from producing another email. Retrying requires the original key, identical fields and fresh valid verification. The inspected ordinary browser form does not add that key. Its timeout therefore does not justify silently replaying the submission. For a team choosing an integration, the useful test is concrete: can the assistant obtain the needed public context, can the person inspect the draft, and does the server enforce its own delivery conditions? Here, MCP provides public reading and WebMCP provides a limited form operation. Keeping their results separate lets the assistant help with the enquiry while leaving a visible, reviewable decision before sending.