FormsPro
Formidable Forms MCP across forms, entries and form actions
Formidable spreads a form across several tables and a set of action posts, and this Formidable Forms MCP integration follows that layout: forms and fields, entries and their stored answers, email notifications, on-submit behaviour, styles, Pro applications and the Stripe payment ledger. Exports mask passwords, cards, uploads, signatures and IPs by default. Entry edits and deletions go through Formidable's hooks and cannot be rolled back from the change log.
Entry 812 on the Membership form is still a draft, but the applicant emailed their missing phone number. Add it and mark the entry complete.
wppilot/formidable-get-entryReadReads entry 812 with its answers keyed by field_key, long values truncated, and shows is_draft is still set.
wppilot/formidable-get-formReadReturns the form's fields so the agent picks the phone field by key rather than guessing an id.
wppilot/formidable-edit-entryConfirm firstMerges the reviewed phone field into the retained answers, updates entry metadata and explicitly fires frm_after_update_entry; check the saved value and downstream listener effects separately.
wppilot/formidable-set-entry-statusConfirm firstClears is_draft; a second identical call reports changed false instead of writing again.
- Edition
- Pro
- Abilities
- 40
- Requires
- WordPress 6.9+, PHP 8.0+, Formidable Forms 6.0.0+, Formidable Pro (Pro fields/features) 6.0.0+
Data model
Tables, action posts and taxonomy terms
Forms live in wp_frm_forms, with a legacy options blob for form settings, and fields in wp_frm_fields, one row each. A submitted entry is a row in wp_frm_items and each answer a row in wp_frm_item_metas, keyed by entry and field. Stripe Lite or Pro adds wp_frm_payments and wp_frm_subscriptions.
Email notifications and the on-submit confirmation are frm_form_actions posts rather than table rows, and Pro applications are terms in the frm_application taxonomy. That mix decides undo: a notification edit is a post the log can snapshot, while forms, fields and entries sit in Formidable's tables and are recorded as irreversible.
Entries have no trash. The is_draft flag marks saved-for-later submissions, not deleted ones, and a form can be told not to store entries at all, in which case Formidable keeps nothing that could be retrieved.
Worked example
Complete an application left in draft
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
Read back the completed status and phone value, then inspect any downstream listener effects. Both writes are logged as irreversible, so retain the reviewed old values separately before changing them.
Field-value illustration: a synthetic masked answer “Old label” becomes “Reviewed label”; this is an example, not a recorded submission.
formidable-get-entryReads entry 812 with its answers keyed by field_key, long values truncated, and shows is_draft is still set.
formidable-get-formReturns the form's fields so the agent picks the phone field by key rather than guessing an id.
formidable-edit-entryMerges the reviewed phone field into the retained answers, updates entry metadata and explicitly fires frm_after_update_entry; check the saved value and downstream listener effects separately.
formidable-set-entry-statusClears is_draft; a second identical call reports changed false instead of writing again.
Abilities
Formidable Forms abilities by effect
Inspect19
formidable-check-setupCheck Formidable Setupformidable-export-entriesExport Formidable Entriesformidable-get-applicationGet Formidable Applicationformidable-get-entryGet Formidable Entryformidable-get-field-types-schemaList Formidable Field Typesformidable-get-formGet Formidable Formformidable-get-form-actionGet Formidable Form Actionformidable-get-form-canonicalGet Formidable Form (Canonical)formidable-get-notificationGet Formidable Notificationformidable-get-subscriptionGet Formidable Subscriptionformidable-get-transactionGet Formidable Transactionformidable-list-applicationsList Formidable Applicationsformidable-list-entriesList Formidable Entriesformidable-list-form-actionsList Formidable Form Actionsformidable-list-formsList Formidable Formsformidable-list-notificationsList Formidable Notificationsformidable-list-stylesList Formidable Stylesformidable-list-subscriptionsList Formidable Subscriptionsformidable-list-transactionsList Formidable Transactions
Create and change7
formidable-add-fieldAdd Formidable Fieldformidable-apply-form-to-applicationApply Form to Applicationformidable-apply-styleApply Formidable Styleformidable-clear-form-from-applicationClear Form From Applicationformidable-create-applicationCreate Formidable Applicationformidable-create-formCreate Formidable Formformidable-create-notificationCreate Formidable Notification
Destructive14
formidable-cancel-subscriptionCancel Formidable Subscriptionformidable-delete-applicationDelete Formidable Applicationformidable-delete-entryDelete Formidable Entryformidable-delete-fieldDelete Formidable Fieldformidable-delete-formDelete Formidable Formformidable-delete-form-actionDelete Formidable Form Actionformidable-delete-notificationDelete Formidable Notificationformidable-edit-entryEdit Formidable Entryformidable-edit-fieldEdit Formidable Fieldformidable-edit-formEdit Formidable Formformidable-edit-form-settingsEdit Formidable Form Settingsformidable-edit-notificationEdit Formidable Notificationformidable-set-entry-statusSet Formidable Entry Statusformidable-set-on-submit-actionSet Formidable On-Submit Action
Reference: /docs/reference/formidable
Documented source abilities; live registration can be narrower. Edition and effect labels describe the source catalogue. The installed schema, dependency versions, licence, WordPress capability, safety profile and per-ability policy determine availability; labels alone do not prove confirmation or recovery.
Limits
Formidable limits worth knowing
- include_sensitive and confirm, where supported, are API prerequisites subject to capability and installed policy, not proof of human consent. Obtain approval for the specific data purpose separately. Permitted fields and exports go to the client/provider; key or pattern masking does not cover arbitrary names or free text. Skill instructions do not enforce a human act.
- Exports mask password, credit-card, file-upload, signature and IP columns unless include_sensitive and confirm are both sent, and masked fields are not searched without that opt-in.
- delete-entry is a hard delete that takes the entry's meta rows with it.
- cancel-subscription changes the local ledger row only. Stripe, PayPal or Square is not contacted, so cancel at the gateway first.
- Deleting a Repeater field leaves its child sub-form behind; delete that form separately, or delete the parent form, which cascades.
- Webhook, post-creation and payment actions can be read and deleted, but creating or editing them is an execute-php job. Formidable and Formidable Pro both need major version 6 or later.
Formidable as a client system
Mapping what a Formidable form does after someone submits
A Formidable form is rarely just a form. Behind it sit form actions: email notifications, a confirmation, perhaps a post created from the entry, a Mailchimp subscribe, a webhook to a CRM, a Stripe charge. Before changing anything on an inherited form, ask the agent for that map. formidable-list-form-actions returns every action on the form across all types with its name, type and enabled flag, and formidable-get-form-action shows any one of them with its settings exactly as stored.
That map answers the questions owners actually ask: why the sales team gets two emails, which forms still post to an old webhook, whether a disabled Mailchimp action is the reason sign-ups stopped. It also sets expectations about what can be changed here. Email notifications and the on-submit behaviour are editable through dedicated abilities; webhook, post-creation and payment actions can be read and deleted but not created or edited, so their fixes happen in Formidable's own screens or as reviewed PHP.
Updating the confirmation: message, redirect or page
Formidable keeps one on-submit action per event, so a form has at most one confirmation for new entries and one for edited entries. formidable-set-on-submit-action replaces it with one of three types: an inline message, a redirect to a URL, or a WordPress page rendered in place. Redirecting to a thank-you page is the common request when a client wants conversions tracked as a page view.
Check two things after the switch. If the form submits by Ajax, confirm the redirect still happens in the browser rather than leaving the visitor on a spinner. And if the form allows entries to be edited later, set the update event too, or an edited entry falls back to whatever confirmation that event still has.
Organising a client's forms with styles and Pro applications
Agencies that build several Formidable forms for one client usually want them to look alike and be easy to find. formidable-list-styles shows the saved styles and which is the default, and formidable-apply-style binds a form to one, so a rebrand can mean designing one style in Formidable's visual styler and then applying it to every form in a single pass. Editing the style itself stays in that styler; the abilities only choose which style a form uses.
On Formidable Pro, applications group related forms, views and pages. formidable-create-application makes one, formidable-apply-form-to-application adds each form, and formidable-get-application lists the members back. Deleting an application only unbinds its forms, so tidying up applications never removes a form or its entries.
- Applying the same style twice reports applied false, so a bulk pass can be re-run safely.
- A style id that does not exist is refused rather than leaving a form unstyled.
- Templates and repeater sub-forms show up in list-forms filters; leave them out of a style sweep unless they render on their own.
Questions
Formidable Forms questions
Where are Formidable success messages set now?
In the on-submit action, which set-on-submit-action writes. The success keys in the form's options blob are a legacy fallback, and edit-form-settings does not accept them.
Can the agent read Stripe payments taken by a Formidable form?
Yes. Transactions and subscriptions are readable whenever the payment tables exist, from Stripe Lite or Pro. Nothing can be charged or refunded.
What happens when a form does not store entries?
Formidable discards each submission after processing it, so list-entries has nothing to return and nothing can be recovered afterwards.
Why is a Formidable entry edit not undoable?
Entries and their answers are rows in Formidable's own tables, which the change log does not snapshot. Read the entry first if you might want the old values back.
Formidable documents an MCP connection for AI agents. GoBuildWP's abilities have their own schemas and permissions; a recipe for another server is not automatically a valid GoBuildWP call. Formidable Forms agent connection guide
Where these facts come from
GoBuildWP behaviour is taken from the plugin source and the ability reference; third-party details from the vendor documentation below, checked by the GoBuildWP team.
Formidable Forms is a separate product; no partnership or endorsement is implied.