How to Test Contact Form 7 AI Filling Without Submission

Quick answer: To test AI-assisted Contact Form 7 filling without sending a message, create a harmless staging form, install ModelGain WebMCP Forms 0.1.0, review and explicitly enable that form under Tools → WebMCP Forms, then open the form page in a WebMCP-capable Chrome test browser. Discover the registered tool, execute it with dummy values, and confirm that only the expected visible fields change. The expected tool result includes ok: true, submitted: false and requiresHumanReview: true. Do not click Send/Submit. This is a local fill-only acceptance test, not a test of email delivery or a real lead submission.

Start here: ModelGain WebMCP Forms exposes an explicitly opted-in, compatible Contact Form 7 form through the experimental browser imperative WebMCP interface. Download the released plugin on WordPress.org. If your browser is not ready, follow our Chrome WebMCP local testing guide; if your form contains checkbox, acceptance, file or other excluded controls, consult the Contact Form 7 field compatibility matrix before enabling anything.

What should a no-submit test actually prove?

There are four separate outcomes. The browser must expose document.modelContext.registerTool; the page must register your exact CF7 form tool; the tool must fill only approved human-visible fields; and neither the tool nor the test should trigger a Contact Form 7 submission. Checking just one outcome is insufficient. An empty inbox is not evidence of a safe test: mail can fail even if a form submitted.

The Chrome imperative WebMCP documentation defines tool discovery and execution. The official ModelGain plugin listing documents its explicit form opt-in and human-only submission boundary. This guide tests that specific plugin implementation, not every WebMCP form strategy or agent.

Step 1: Make a staging Contact Form 7 form using safe fields

Use a WordPress staging environment that you control. For ModelGain WebMCP Forms 0.1.0, verify WordPress 6.9+, PHP 7.4+, and an installed, active Contact Form 7. Keep production contact data, CRM integrations, real customer email recipients and payments out of this test. Create a dedicated CF7 form such as Agent Fill Smoke Test:

<label>Name [text* your-name]</label>
<label>Email [email* your-email]</label>
<label>Topic [select your-topic "Support" "Sales"]</label>
<label>Message [textarea your-message]</label>
[submit "Send"]

The form’s input names are deliberately simple and stable. The text, email, single-select and textarea controls are included in the v0.1.0 allowlist; the regular submit button is deliberately not an agent input. Put this form on one HTTPS staging page. Choose a test page with exactly one visible instance of the enabled CF7 form: duplicated instances of the same form ID can make the runtime refuse ambiguous registration.

Do not simplify a real customer form by removing consent, file uploads, CAPTCHA or anti-spam requirements. The released adapter uses a fail-closed policy: an unsupported explicit CF7 field can block the entire form. A separate minimal test form is safer than weakening your production form. See which CF7 fields are supported and the original Contact Form 7 documentation.

Step 2: Install the plugin and explicitly enable only that form

1. Install ModelGain WebMCP Forms v0.1.0 from WordPress.org alongside Contact Form 7; do not install the plugin on modelgain.com merely to follow this tutorial.
2. In WordPress admin open Tools → WebMCP Forms. Find the specific staging form and inspect its compatibility, allowed fields, blocked controls and resolved tool name.
3. If the form is marked incompatible, do not override the decision. Inspect the exact CF7 tags, duplicate names, missing select options and any unsupported extension controls. Fix only the isolated staging form.
4. Explicitly enable the one compatible form, save the setting and note its actual registered tool name. New forms are disabled by default; activation of the plugin is not consent to expose all forms.
5. Open the public staging form URL in a suitable experimental Chrome build. Verify the normal human form still renders before invoking WebMCP.

The plugin does not include an AI agent or an MCP server. It registers a browser-side tool only when that browser supports the required WebMCP interface. The browser’s testing flag is separate from WordPress configuration.

Step 3: Check Chrome’s WebMCP interface and registered tool

Chrome documents local testing through chrome://flags/#enable-webmcp-testing, followed by a browser relaunch. The API is experimental and may vary by build, so consult the current Chrome overview rather than assuming an ordinary browser has it enabled. On your staging form’s HTTPS URL, open DevTools → Console and run this read-only check:

typeof document.modelContext?.registerTool
// Expected: "function" in a supported test environment

Then check whether the plugin reports successful registration:

window.ModelGainWebMCPFormsDiagnostics?.tools
// Look for your actual tool name with status: "registered"

This diagnostics object is specific to the current ModelGain v0.1.0 frontend runtime. It is not a WebMCP standard API. A status of unsupported, not_present, ambiguous or registration_failed needs its own investigation. In particular, a form ID rendered twice on the same page can produce ambiguous.

Where supported by the current browser API, list accessible tools without invoking them:

const tools = await document.modelContext.getTools();
console.table(tools.map(tool => ({
  name: tool.name,
  description: tool.description
})));

Compare the returned name with the one in Tools → WebMCP Forms. Do not guess a name from the form title or copy the tool name from someone else’s screenshot. If the list is empty, verify browser support, plugin registration status, the page’s form ID and document/frame context before moving on.

Step 4: Execute a safe fill-only test

In this example the staging form has exactly four named user fields. Replace PASTE_TOOL_NAME_FROM_ADMIN with the actual registered name from the WordPress admin registry, not a fabricated tool name. Chrome’s documented executeTool() method is available in supported test builds. Run this only in the already reviewed, isolated staging page:

{
  const toolName = "PASTE_TOOL_NAME_FROM_ADMIN";
  const tools = await document.modelContext.getTools();
  const tool = tools.find(item => item.name === toolName);
  if (!tool) throw new Error("The expected WebMCP tool is not registered");
  const result = await document.modelContext.executeTool(tool, {
    "your-name": "Example Tester",
    "your-email": "[email protected]",
    "your-topic": "Support",
    "your-message": "WebMCP fill-only staging test; do not submit."
  });
  console.log(result);
}

On ModelGain WebMCP Forms 0.1.0, the expected result from the plugin is ok: true, submitted: false, requiresHumanReview: true, an empty rejectedFields array, and filledFields containing the four matching field names. The input and change events update the visible controls. Read the actual returned object instead of treating this example as a guarantee for a different form, build or agent environment.

Visually inspect the staging form: all four dummy values should match, the form should still be on the page and the Submit button should not have been activated. A successful field fill is not a successful Contact Form 7 submission; no validation, spam check, email delivery, lead creation or webhook is being claimed.

Step 5: Verify that the test did not send a message

Before executing the tool, open DevTools → Network, clear old traffic and enable Preserve log if useful. Filter for requests related to Contact Form 7’s submission path, commonly involving the form’s /feedback endpoint. Perform the fill-only test once. There should be no submission request attributable to that tool call. Other page requests or third-party analytics can occur normally, so investigate request initiators instead of assuming every network request indicates a form submission.

For a stronger acceptance test, use an isolated staging environment with a test mailbox or disabled outbound delivery plus a server-side submission/event log that you control. Compare before/after counts. Neither a silent inbox nor a browser network panel alone proves that no other plugin or backend action occurred. A test recipient or disabled mail transport does not replace checking whether CF7’s submission path was invoked.

Do not click Send to complete this test. If you intentionally want to test the human submission path later, treat that as a separate case with its own sandbox recipients, validation and email-delivery checks. The ModelGain tool has no code path calling submit() or requestSubmit() and should report submitted: false after it fills fields.

Step 6: Run a negative test—invalid input must not partially fill

The adapter’s current runtime validates its complete input object before applying changes. With your four-field staging form reset to empty, try an input containing an unrecognized property, or omit the required your-email field. A browser may reject an invalid call at its JSON Schema boundary; otherwise the plugin can return ok: false and a rejectedFields list. Both outcomes should leave the form unchanged:

{
  const toolName = "PASTE_TOOL_NAME_FROM_ADMIN";
  const tool = (await document.modelContext.getTools())
    .find(item => item.name === toolName);
  if (!tool) throw new Error("Expected tool missing");
  const result = await document.modelContext.executeTool(tool, {
    "your-name": "Should Not Appear",
    "unknown-field": "blocked"
  });
  console.log(result);
}

Because the required email is absent and unknown-field is not permitted, the plugin’s own contract rejects the complete request before changing any fields. If the browser rejects the call before plugin execution, you may see an API error instead of the plugin’s JSON result—do not mistake that for a successful fill. Confirm no visible field changed and no form submission occurred. An invalid email, a nonexistent select choice or an invalid calendar date should also fail rather than being coerced into a successful action.

These failure paths are covered by the released project’s runtime tests, which also cover tool registration and cleanup. They are still local plugin behavior, not proof that an unrelated browser agent, extension or conditional-field integration is safe.

How to troubleshoot a failed no-submit test

Chrome’s imperative API reference and WebMCP DevTools guide explain the browser side. Discussions about pre-filled form state and validation feedback before submission illustrate why a visible field change and a later server-accepted form are separate states. Those discussions are evolving design questions, not established guarantees of ModelGain functionality.

Acceptance checklist before you use this on a real site

• Scope: You tested the real released ModelGain v0.1.0 plugin against Contact Form 7 on an isolated staging site, not a different form builder.
• Compatibility: The complete form contains only supported fields; no acceptance, checkbox, upload, sensitive, hidden or other blocked user form-tags.
• Opt-in: Only the intended staging form was explicitly enabled; other forms remain off by default.
• Browser: The imperative API was actually exposed in the correct secure document, and the expected tool name was registered.
• Positive test: Harmless values filled the expected controls, the returned fields matched and the tool reported submitted: false.
• Negative test: Invalid input was rejected without partial changes or form submission.
• Submission boundary: The network/server observations did not show a CF7 submission caused by the tool, and the human Submit button was not activated.
• Fallback: The ordinary Contact Form 7 form still works for human users when browser WebMCP support is absent.

Passing these checks supports a limited fill-only staging deployment. It does not authorize automatic live lead submission, consent selection, CAPTCHA bypass, payment or credential handling. For business-critical forms, separately assess privacy, mail routing, form validation and every downstream integration.

Next steps: from first test to controlled rollout

If all checks pass, document the form ID, tool name, browser build, allowed fields, positive/negative results and whether any network feedback request was observed. Keep the user in control of all consequential submission steps. If the test fails because your live form needs checkboxes, consent or uploads, use a human-only flow for that form rather than weakening safeguards.

Read the ModelGain WebMCP Forms product page for supported behavior and limitations, use the official WordPress.org listing for the installation, and follow the complete setup guide if your first form is not yet configured. The intended result is a verifiable, reversible, fill-only user experience—not a claim that an AI agent can safely send every business form.