0 items
Sign in
Buy

Docs

GravityKit MCP tools reference

Estimated reading: 7 minutes

Updated on October 6, 2026

GravityKit MCP exposes two independent sets of tools. The Gravity Forms tools, named with a gf_ prefix, are always present when your Gravity Forms credentials work. The GravityKit product tools are generated at runtime from the connected site, so which ones exist depends on the GravityKit products installed there.

A site with only Gravity Forms lists the gf_ tools and gk_reload_abilities, and a GravityKit site without Gravity Forms REST credentials still lists its product tools.

You never type these names. They are what your assistant sees and chooses between when you describe what you want. Knowing them helps when you want to be specific (“use the validation tool, don’t submit it”) or when you are reading back what the assistant did.

Gravity Forms tools #

Forms

  • gf_list_forms: list the site’s active forms. Name form IDs to fetch specific forms, including inactive or trashed ones. There is no search or paging, so the assistant filters the list it gets back.
  • gf_get_form: read a form’s complete configuration.
  • gf_create_form: create a form, with fields.
  • gf_update_form: update a form. Settings you leave out are kept, but a list you send, such as the form’s notifications or fields, replaces the stored one. If that would drop a field, a confirmation, a notification, or another stored setting, the update is refused and the message names what would be lost, unless the request names that property in replace. Lists without IDs, such as a field’s choices, are replaced as sent.
  • gf_delete_form: move a form to Trash, or delete it permanently with force. Requires GRAVITY_FORMS_ALLOW_DELETE=true.
  • gf_validate_form: check field values against a form’s validation rules without saving anything.

Entries

  • gf_list_entries: list and search entries, 10 at a time unless the request asks for a different page size. Supports paging, sorting, field filters with any/all matching and operators including IN and NOT IN, fetching by ID, exclusions, status, and querying several forms at once.
  • gf_get_entry: read a single entry.
  • gf_create_entry: create an entry. A full card number, security code, expiration date, or cardholder name in a Credit Card field is refused. So is a value in a Password field, because the entries API would store both as sent. A masked card number is accepted, and gf_submit_form_data masks a full one the way a form submission does.
  • gf_update_entry: update an entry, with the same checks. Fields you leave out keep their values.
  • gf_delete_entry: move an entry to Trash, or delete it permanently with force. Requires GRAVITY_FORMS_ALLOW_DELETE=true.

Fields

  • gf_add_field: add a field where you ask for it. A malformed position is refused. If the field it should follow isn’t on the form, or an index is out of range, the field is placed elsewhere and the response says where.
  • gf_update_field: update a field. Changing its type, choices, or inputs is refused while conditional logic, a calculation, or a merge tag depends on it, unless the request confirms the change. Changes to its label or description always go through. Changing a checkbox’s choices renumbers its inputs, the way the form editor does, and the response warns when saved entries keep values under the old numbers.
  • gf_delete_field: delete a field. A deleted field does not go to the Trash. If conditional logic, a calculation, or a merge tag depends on the field, the deletion has to be confirmed, and the dependent conditional logic can be removed with it. Calculations and merge tags that still refer to the field are reported. Requires GRAVITY_FORMS_ALLOW_DELETE=true.
  • gf_list_field_types: list the 46 field types the server carries definitions for. The detailed listing adds the storage format each one uses.

Field types added by other plugins work too. The server has no built-in defaults or sub-inputs for them, so a custom compound field needs its inputs supplied, and a choice field its choices. A field that stores its answers as checkboxes is the exception for inputs: the server creates one input per choice, the same as the form editor does.

Submissions

  • gf_submit_form_data: submit a form with full processing, the same as a visitor submitting it.
  • gf_validate_submission: check a submission against the form’s validation rules without creating an entry.

Both take field values as input_1, input_2, and so on. A field_values parameter is refused, because Gravity Forms ignores it on this route.

Add-on feeds

Feeds are how Gravity Forms add-ons, such as Mailchimp, Stripe, and PayPal, decide what happens when a form is submitted.

  • gf_list_feeds: list active feeds for a form, an add-on, or the whole site. An inactive feed is not listed; read it by ID with gf_get_feed.
  • gf_get_feed: read one feed’s configuration, active or not.
  • gf_create_feed: create a feed, active or inactive.
  • gf_update_feed: replace a feed’s settings. If the new settings leave out ones the feed has, the update is refused and the message names them, unless the request says to replace them on purpose.
  • gf_patch_feed: change only the feed settings you send and keep the rest.
  • gf_delete_feed: delete a feed permanently. Requires GRAVITY_FORMS_ALLOW_DELETE=true.

Notifications and results

  • gf_send_notifications: send an entry’s notifications, either specific ones or all notifications for an event. The response lists the notifications Gravity Forms handed to its mailer, or says why it sent none. It does not confirm delivery, and it skips an inactive notification, or one whose conditions aren’t met, without mentioning it. Recipients come from each notification’s own settings.
  • gf_get_field_filters: list the filters available for a form, which is what makes a precise entry search possible.
  • gf_get_results: get aggregated results for Quiz, Poll, and Survey forms, optionally limited to the entries a search matches.

GravityKit product tools #

When GravityKit Foundation is active on the connected site, GravityKit products publish their capabilities as “abilities” through Foundation and the WordPress Abilities API, which WordPress added in version 6.9. The server reads that catalog when it starts and turns each ability into a tool, so the exact set depends on which products and versions are installed. Each product gets its own prefix.

GravityView 3.0 and later publishes tools under the gv_ prefix. They cover the View lifecycle (creating a View, applying a configuration, deleting it), field, widget, search, and grid editing, and discovery calls that report what layouts and field types the site offers. Setup and examples are in Creating Views with AI using the GravityKit MCP.

GravityMigrate 2.1 and later publishes tools under the gmig_ prefix. They list forms and the form plugins it can migrate between, run a migration or a dry run of one, and export, inspect, and import migration bundles. Setup and examples are in Migrating forms with AI using the GravityKit MCP.

Product tools marked as destructive, such as gv_view_delete, appear in the list but stay disabled until you permit them. The other product tools, including the ones that edit a View, work by default. See Destructive product tools.

Because both sets are available at once, you can create a form and build a View for it in a single conversation.

One more tool belongs to neither set: gk_reload_abilities re-reads the GravityKit catalog. Ask your assistant to reload abilities after you activate or update a GravityKit product, and its tools appear without restarting the app. The reply also names the site the product tools use and the settings their credentials come from, and lists any ability that did not become a tool, with the reason.

To see what your site offers, ask the assistant directly, for example “What GravityKit tools do you have?” It reports the catalog it loaded, which is more reliable than any list written down here.

Was this page helpful?

Table Of Contents