--- title: "GravityKit MCP configuration settings" date: 2026-08-17 updated: 2026-10-02 author: "Block MCP (service account)" link: "https://www.gravitykit.com/docs/gravitykit-mcp/configuration/" category: "GravityKit MCP" --- 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](https://www.gravitykit.com/docs/gravitykit-mcp/getting-started/), 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](https://github.com/GravityKit/MCP/releases/latest/download/gravitykit-mcp.mcpb), 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](https://github.com/GravityKit/MCP) has an `.env.example` file with sample values, including the settings its test suite uses.