DEVELOPER TOOLS
Which Contact Form 7 Field Types Work with WebMCP?
Check which Contact Form 7 fields work with ModelGain WebMCP Forms, why checkboxes and uploads block a form, and how to test safely.
FREE WORDPRESS PLUGIN
ModelGain WebMCP Forms
Let a WebMCP-capable browser agent fill approved Contact Form 7 fields, while the visitor stays in control of submission.
- Install alongside Contact Form 7
- Enable one compatible form
- Let the visitor review and submit
Requires Contact Form 7, WordPress 6.9+, PHP 7.4+ and a browser exposing WebMCP. Explicit opt-in; only supported visible fields. Never submits forms or bypasses validation and anti-spam safeguards.
Quick answer: ModelGain WebMCP Forms v0.1.0 can let a compatible browser agent fill Contact Form 7 text, email, URL, telephone, number, date, textarea, single-select and radio fields. It does not expose checkbox, acceptance, file upload, quiz, CAPTCHA, hidden, sensitive, multiple-select or unknown controls. One blocked field makes the entire form ineligible for WebMCP exposure in this release—even if the other fields are supported. The normal human Contact Form 7 form remains available and the plugin never submits it.
Check your form before installation: Open the form in Contact Form 7, identify its form-tags, then compare them with the table below. To try a compatible form on a staging site, install ModelGain WebMCP Forms from WordPress.org; see our Contact Form 7 WebMCP setup guide and Chrome WebMCP browser preflight. This article describes the ModelGain adapter’s current support, not every field Contact Form 7 itself or every WebMCP implementation can handle.
Supported Contact Form 7 fields: the v0.1.0 compatibility table
These are the explicit allowlisted Contact Form 7 base types in the published ModelGain WebMCP Forms v0.1.0 listing. Contact Form 7’s asterisk variants normally mark required fields; required status alone does not disqualify an otherwise supported type. The plugin still checks safe field names, available options and the compatibility of the whole form.
| CF7 form-tag | ModelGain WebMCP Forms 0.1.0 | Important condition |
|---|---|---|
text, text* |
Supported | Visible, non-sensitive text field with a valid unique name |
email, email* |
Supported | Still subject to normal CF7 validation |
url, url* |
Supported | Ordinary URL field; not an arbitrary file or link action |
tel, tel* |
Supported | Telephone data is filled for human review |
number, number* |
Supported | Use a normal numeric control and verify values on the rendered form |
date, date* |
Supported | Native date input; verify browser formatting |
textarea, textarea* |
Supported | Multi-line text; not a rich-text editor or file uploader |
select, select* |
Supported conditionally | Exactly one selected value; options must be defined; multiple is blocked |
radio |
Supported conditionally | Must have at least one declared choice |
The source-of-truth distinction is important: Contact Form 7’s own text-field documentation and choice-control documentation explain which form-tags CF7 can render. ModelGain’s additional allowlist and fail-closed rules determine whether those tags may be included in a browser-agent tool.
Unsupported fields: what blocks the entire WebMCP form?
| CF7 field or pattern | ModelGain v0.1.0 decision | What to do |
|---|---|---|
checkbox, checkbox* |
Blocked | Keep multi-choice inputs in the ordinary human form |
acceptance (consent) |
Blocked | Do not remove required agreement or privacy controls |
file, file* |
Blocked | Use the normal human upload workflow; never ask the agent to upload |
select with multiple |
Blocked | Use a separate single-choice staging test when appropriate |
quiz, CAPTCHA, anti-spam fields |
Blocked | Retain anti-spam controls; do not bypass them |
hidden form-tags, security/credential fields |
Blocked | Never expose provider internals, secrets or payment credentials |
| Custom/unknown tags, duplicate names, invalid names or choice fields without options | Blocked | Review the exact registry reason; do not assume compatibility |
submit |
Not an agent field | Ordinary CF7 submission stays a human action; the submit button itself is ignored when enumerating user input tags |
Why not simply ignore the unsupported field? A required agreement, document, custom conditional input or anti-spam control might determine whether a form is valid. Pretending the form is completely represented by an AI tool when some controls are missing could create misleading schemas or unsafe assumptions. The adapter therefore refuses to expose a form containing policy-blocked tags. It does not rewrite the form, delete required controls, or silently discard a checkbox and proceed.
A subtle exception needs precise wording: Contact Form 7 also generates internal implementation inputs during rendering. The adapter derives its field contract from scanned CF7 form-tags, rather than treating every hidden internal DOM input as an agent parameter. Do not infer from that that an explicitly authored [hidden ...] tag is allowed; a user-authored hidden form-tag is outside the supported allowlist.
Check if your Contact Form 7 form can be exposed to WebMCP
Applies when: ModelGain WebMCP Forms v0.1.0 compatibility and safe next steps for Contact Form 7 field types.
Quick answer
Supported user fields are text, email, URL, tel, number, date, textarea, single-select and radio. Any blocked form-tag makes the complete form incompatible; browser support and explicit per-form opt-in are also required. Filling does not submit.
What to do
-
Open the Contact Form 7 form editor and identify both ordinary visible inputs and consent, upload, hidden, security, multiple-select and extension-provided tags.
-
Review the real admin registry's supported and blocked fields for that exact form; an apparently simple visible form can still contain a blocked control.
-
Explicitly enable one compatible form, verify the imperative WebMCP API and tool registration in a supported browser, and test harmless filling with no submission.
What does the form contain or what is blocking you?
All paths are listed below. Select a symptom to focus on the most relevant path.
Review the full field registry before enabling
Confirm every CF7 form-tag has an allowed type, valid non-sensitive unique name and no form-wide block. New forms stay disabled until a site administrator explicitly opts in.
Verify single-choice options
Only a single-select with declared options or a radio group with at least one option belongs to the supported set. Multiple select and checkbox groups are blocked; a missing option can block the form.
Retain essential human-only controls
In v0.1.0 any blocked user form-tag prevents the entire form from being exposed. Do not delete acceptance, CAPTCHA or file upload checks to qualify a live form. Consider a separate staging-only example.
Do not assume a dynamic form has a stable field contract
Review extension-provided tags and conditional validation on the rendered form. Unknown or unsupported controls fail closed; the plugin does not promise generic conditional-field integrations.
Separate form compatibility from browser registration
Verify the form was explicitly enabled, then confirm document.modelContext.registerTool is exposed in a supported Chrome test context. Browser support does not create tools automatically.
Did this help?
Two sample CF7 forms: one eligible, one blocked
Minimal supported staging form
This is a representative test form, not a production consent pattern. Create it in a controlled WordPress staging site with a normal Contact Form 7 installation:
<label>Name [text* contact-name]</label>
<label>Email [email* contact-email]</label>
<label>Reason [select contact-reason "Support" "Sales"]</label>
<label>Preferred reply [radio reply-method "Email" "Phone"]</label>
<label>Message [textarea contact-message]</label>
[submit "Send"]The five user input tags belong to the supported set, their field names are unique and each choice field declares options. The submit button is left under normal Contact Form 7 control. This only passes the basic type check: the administrator must still review the actual registry result and explicitly opt in; the browser must implement imperative WebMCP; the agent must be tested on the rendered form. A form being structurally eligible does not itself send anything.
The same form becomes incompatible if you add a consent checkbox or upload
[acceptance privacy-consent] I agree to the privacy terms. [/acceptance]
[file attachment filetypes:pdf limit:2mb]Adding either of these CF7 controls causes the ModelGain v0.1.0 compatibility policy to reject the whole form. Both controls are legitimate Contact Form 7 functionality; they are just excluded from this particular AI-facing adapter. CF7 acceptance documentation explains the human consent mechanism, and its upload documentation covers normal attachments. Do not strip consent, file-size checks or CAPTCHA from an existing real customer form to make the WebMCP registry show “Compatible.”
For a site that genuinely needs those controls, retain the full human workflow. If a separate, simplified staging form can represent a safe non-consequential task, test the plugin there. A visually similar second live form is not a substitute for reviewing consent, privacy and the site’s actual business obligations.
How to check why your form is marked incompatible
- Check prerequisites. ModelGain v0.1.0 requires WordPress 6.9+, PHP 7.4+ and Contact Form 7. Use a staging site rather than a live lead-collection form for first tests.
- Inspect the exact CF7 form definition. In WordPress admin, open Contact → Contact Forms and select the form. Identify every tag, not just fields visually noticeable on the frontend. Look for acceptance, checkbox, file, multiple-select, hidden, quiz, CAPTCHA and third-party dynamic fields.
- Open Tools → WebMCP Forms. Inspect the form registry’s compatibility result, supported-field list and blocked-field reasons. A newly discovered form starts disabled; do not assume installing the adapter automatically exposes all forms.
- Resolve only safe staging issues. For a test-only form, correct duplicate field names or add missing select/radio choices. If you encounter a consequential field such as consent or file upload, keep the real form untouched and choose the regular human path instead.
- Enable the one reviewed compatible form. Explicitly opt in after verifying its effective field schema and resolved tool name. Do not bulk-enable unreviewed customer forms.
- Verify the browser separately. In a supported Chrome build, check
typeof document.modelContext?.registerToolon the HTTPS page. The function must exist before debugging registration. Our Chrome WebMCP local testing guide gives the browser setup and discovery steps. - Verify fill without submission. Use an actual WebMCP-capable test agent, populate only harmless sample values and inspect the visible form. Confirm no mail, lead record or request was sent. The user still has to review and submit through Contact Form 7.
What about conditional fields and third-party CF7 extensions?
Do not treat a dynamic form as automatically compatible because its currently visible controls happen to be text fields. Third-party conditional forms can add their own form-tags, hide required values, or change which controls exist after a selection. ModelGain v0.1.0 is not an adapter for arbitrary conditional-field plugins and has no general promise of updating a tool schema as a complex form changes.
The broader issue is documented in the WebMCP discussion of declarative APIs for JavaScript-driven forms: rendered inputs do not always express the complete form state. Separately, CF7 extension support reports show that hidden conditional required fields can affect ordinary validation, independently of WebMCP. These are reasons to test a specific integration, not proof that ModelGain causes those third-party issues.
Also keep WebMCP’s two approaches distinct. Chrome’s declarative form annotations and its imperative JavaScript tools are separate developer strategies. ModelGain WebMCP Forms v0.1.0 uses the imperative path and its own allowlisted CF7 form model. A field supported by the browser’s declarative approach is not thereby supported by this plugin.
File-upload security note for Contact Form 7 users
On October 29, 2026, the Contact Form 7 project published version 6.2.4 with security fixes, including a fix for an unauthenticated arbitrary-file-upload issue affecting versions 6.2 through 6.2.3. If your WordPress site uses Contact Form 7, check your installed version and follow the official update guidance, testing any affected file-handling behavior. Updating Contact Form 7 is separate from WebMCP Forms compatibility: upgrading CF7 does not make file inputs an allowed WebMCP field or remove the need for normal form security controls.
Frequently asked field-compatibility questions
Can a Contact Form 7 checkbox be filled through this plugin?
No. checkbox and checkbox* are not supported in ModelGain WebMCP Forms 0.1.0. The entire CF7 form is ineligible for WebMCP exposure if it contains a blocked checkbox tag. A radio group can be supported when it declares valid options, but radio and checkbox are not functionally interchangeable; don’t change a multi-choice business question into a single-choice one purely to pass compatibility.
Are required fields supported?
Yes, a supported base type can also be required (for example text* and email*). This does not override blocked types: a required file or checkbox field is still blocked. Normal Contact Form 7 validation remains authoritative at human submission time.
Does a GDPR/privacy agreement count as a supported field?
No. The acceptance tag is blocked, and the plugin does not claim legal consent management, consent recording or a GDPR compliance guarantee. A visitor must handle required agreement through the site’s regular, appropriately designed human form. Don’t substitute auto-filled text for a deliberate consent choice.
Can an agent upload a CV, photo or PDF through WebMCP Forms?
No. File controls are excluded. The plugin does not grant file-system access, upload documents or bypass WordPress upload restrictions. Retain the normal upload path and CF7’s current security protections.
Why does the tool not appear even though all my fields look supported?
Review the exact blocked-field report and form opt-in first. A name matching the policy’s sensitive-control patterns, duplicated field names, absent choice options or an extension-provided unknown field may prevent exposure. Then check whether the browser exposes the imperative WebMCP API and whether the tool was registered on the actual form page. Follow the browser-versus-registration checklist rather than repeatedly reinstalling the plugin.
Decision: use this plugin, simplify a test form, or keep human-only?
Use ModelGain WebMCP Forms when you have an opt-in Contact Form 7 form containing only supported, non-sensitive user fields, a compatible experimental browser and a safe fill-only task. Use a separate staging test form when your live form includes essential unsupported controls but you want to evaluate WebMCP. Keep the regular human form when consent, CAPTCHA, documents, sensitive inputs, complex conditional behavior or consequential submission is integral to the workflow.
Start with the ModelGain WebMCP Forms product page, download the verified release from WordPress.org, and use the controlled Contact Form 7 setup guide. For the browser-level prerequisite, read How to Enable WebMCP in Chrome for Local Testing. The outcome to verify is a correctly registered form tool that fills only approved fields and never submits without the human—not simply a green compatibility label.