0 items
Sign in
Buy

Docs

GravityKit MCP configuration settings

Estimated reading: 6 minutes

Updated on October 2, 2026

Every GravityKit MCP setting is an environment variable. Set them in the env block of your MCP client’s server definition, as shown in Getting started with GravityKit MCP, or in a .env file if you run the server from a local clone.

The Claude Desktop extension sets only the site, the credentials, and the two delete settings, from its setup form. For any other setting, such as accepting a local site’s self-signed certificate, add the server through the configuration file instead.

Required settings #

  • GRAVITY_FORMS_BASE_URL: your WordPress site URL, with no trailing slash.
  • GRAVITY_FORMS_CONSUMER_KEY: your WordPress username when you are using an application password, or a Gravity Forms Consumer Key (ck_…).
  • GRAVITY_FORMS_CONSUMER_SECRET: the application password, or the matching Consumer Secret (cs_…).

Optional settings #

  • GRAVITY_FORMS_ALLOW_DELETE (default false): allow the Gravity Forms delete tools to run, and every destructive product tool while the next setting is empty. See below.
  • GRAVITYKIT_MCP_ALLOW_DESTRUCTIVE (default empty): which destructive GravityKit product tools may run. See below.
  • GRAVITY_FORMS_TIMEOUT (default 30000): how long, in milliseconds, the server waits for your site to answer a request.
  • GRAVITYKIT_TIMEOUT (defaults to GRAVITY_FORMS_TIMEOUT): the same wait, for the GravityKit product tools only.
  • GRAVITY_FORMS_MAX_RETRIES (default 2): how many more times the server tries to load the GravityKit product tools when your site is busy (it answers 429, 502, 503, or 504) or does not answer. Requests that tools make are not retried.
  • GRAVITYKIT_MCP_LIST_TIMEOUT_MS (default 2000): how long, in milliseconds, the first tool list waits for the GravityKit product tools to load. Raise it for a client that reads the list only once, such as Claude Code run with claude -p.
  • GRAVITY_FORMS_DEBUG (default false): detailed logging.
  • GRAVITY_FORMS_ALLOW_SELF_SIGNED_CERTS (default false): accept self-signed SSL certificates. Local development only.
  • GRAVITY_FORMS_ALLOW_HTTP_BASIC_AUTH (default false): permit Basic authentication to a remote plain-HTTP host. Your credentials are visible to the network when this is on.
  • GRAVITY_FORMS_AUTH_METHOD: force basic or oauth. Normally leave this unset; see below.

Debug logging records each Gravity Forms request’s method and URL, the response status, and which authentication method was selected. Request and response bodies are not written to the log, and keys and secrets in a URL are masked. Error messages from your site are logged whether debug logging is on or not.

How the server authenticates #

The server picks the transport from the shape of your credentials and the URL. You normally configure nothing:

  • Application password (username plus app password) uses Basic authentication over HTTPS, or over any local URL (localhost, *.test, *.local). WordPress authenticates the user; Gravity Forms enforces that user’s capabilities.
  • A Gravity Forms key pair over HTTPS uses Basic authentication.
  • A Gravity Forms key pair over plain HTTP uses OAuth 1.0a automatically. Gravity Forms accepts key-pair Basic authentication only over HTTPS, so OAuth is the only transport that works there.
  • A remote plain-HTTP host refuses Basic authentication unless you allow it with GRAVITY_FORMS_ALLOW_HTTP_BASIC_AUTH=true or force it with GRAVITY_FORMS_AUTH_METHOD=basic. Either way, the server logs a warning.

Set GRAVITY_FORMS_AUTH_METHOD only to override that choice. Whatever the transport, access stays limited to the WordPress user’s capabilities, or to the API key’s permission level.

Deleting forms, entries, feeds, and fields #

Deletion is off by default. With GRAVITY_FORMS_ALLOW_DELETE unset or false, gf_delete_form, gf_delete_entry, gf_delete_feed, and gf_delete_field refuse to run and return: Delete operations are disabled. Set GRAVITY_FORMS_ALLOW_DELETE=true to enable.

With it set to true, deleting a form or an entry moves it to Trash, where you can restore it from WordPress. Only a request that explicitly passes force deletes permanently. A deleted feed or field is removed for good, since neither has a Trash.

In the Claude Desktop extension, the Allow Claude to delete and overwrite your data checkbox sets this to true.

Local development #

Local development tools such as Laravel Valet, MAMP, and Local WP can serve a site with a self-signed SSL certificate, which the server rejects by default. Add this to the env block to accept it:

"GRAVITY_FORMS_ALLOW_SELF_SIGNED_CERTS": "true"

Turning off certificate verification is for local development only. Never set this against a production site.

GravityKit product tools #

When GravityKit Foundation is active on the connected site, the server also loads the tools your GravityKit products publish. The products publish them through the WordPress Abilities API, which WordPress added in version 6.9. On a single site they need no extra configuration: they use your GRAVITY_FORMS_* values, which must then be a WordPress username and application password.

Override these only when the WordPress root differs from the Gravity Forms URL, or when you want the product tools to use a separate credential:

  • GRAVITYKIT_WP_URL: defaults to GRAVITY_FORMS_BASE_URL.
  • GRAVITYKIT_WP_USERNAME: defaults to GRAVITY_FORMS_CONSUMER_KEY.
  • GRAVITYKIT_WP_APP_PASSWORD: defaults to GRAVITY_FORMS_CONSUMER_SECRET.

Set the username and the password together. With only one of them set, the server ignores it and keeps using the Gravity Forms pair.

If GRAVITYKIT_WP_URL has a different host than GRAVITY_FORMS_BASE_URL, the product tools and the Gravity Forms tools work on different sites. The server logs a warning naming both URLs when it starts, and the reply from gk_reload_abilities names both too.

These tools authenticate with a WordPress application password over Basic authentication, so like the Gravity Forms tools they refuse a remote plain-HTTP URL unless GRAVITY_FORMS_ALLOW_HTTP_BASIC_AUTH is true. HTTPS and local URLs are always accepted.

Destructive product tools

A product tool marked as destructive stays disabled until you permit it. The other product tools, including the ones that edit a View, work by default. In GravityView, the destructive tools delete a View, change a View’s status (to publish it or move it to the Trash, for example), or remove a field, widget, search field, grid row, or preview. In GravityMigrate, they import a migration bundle, which can overwrite this site’s settings, or reset the migration state.

A tool that declares neither destructive nor readonly counts as destructive, so a product that has not said which it is errs toward warning your assistant.

GRAVITYKIT_MCP_ALLOW_DESTRUCTIVE is a comma-separated list of what you permit. Each entry is one of:

  • all: every destructive product tool
  • A product prefix, which is the part of a tool name before the first underscore: gv for GravityView, gmig for GravityMigrate
  • An exact tool name, such as gv_view_delete

This env entry permits every GravityMigrate tool and lets the assistant change a View’s status, while gv_view_delete and GravityView’s removal tools stay off:

"GRAVITYKIT_MCP_ALLOW_DESTRUCTIVE": "gmig, gv_view_status_set"

A tool you have not permitted still appears in your assistant’s tool list, with its description saying it is disabled and naming what to add. Calling it returns: gv_view_delete is a destructive operation and is disabled on this server. Add “gv_view_delete” (or its product prefix, or “all”) to GRAVITYKIT_MCP_ALLOW_DESTRUCTIVE to enable it.

Leaving the list empty and setting GRAVITY_FORMS_ALLOW_DELETE=true permits every destructive product tool. Naming anything in GRAVITYKIT_MCP_ALLOW_DESTRUCTIVE takes over, so the list wins where both are set. Either way, GRAVITY_FORMS_ALLOW_DELETE is still what governs the Gravity Forms delete tools described above.

In the Claude Desktop extension, these are the last two fields of the setup form: Allow Claude to delete and overwrite your data sets GRAVITY_FORMS_ALLOW_DELETE, and Allow only some destructive tools (optional) sets GRAVITYKIT_MCP_ALLOW_DESTRUCTIVE.

Pointing the server at a test site #

To work against a staging site, give the server that site’s address and credentials in GRAVITY_FORMS_BASE_URL, GRAVITY_FORMS_CONSUMER_KEY, and GRAVITY_FORMS_CONSUMER_SECRET. The GravityKit product tools follow the same site unless GRAVITYKIT_WP_URL says otherwise.

The GRAVITY_FORMS_TEST_* settings and GRAVITYKIT_MCP_TEST_MODE are for running the server’s own test suite from a local clone. Test mode also writes the server’s log to the channel your AI app reads, so leave it off in an AI app’s configuration.

The GravityKit MCP repository has an .env.example file with sample values, including the settings its test suite uses.

Was this page helpful?

Table Of Contents