---
title: "GravityKit MCP configuration settings"
date: 2026-08-17
author: "Block MCP (service account)"
link: "https://www.gravitykit.com/docs/gravitykit-mcp/configuration/"
---

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](/docs/gravitykit-mcp/getting-started/), or in a `.env` file if you run the server from a local clone.

## 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 delete tools to run. See below.
- `GRAVITY_FORMS_TIMEOUT` (default `30000`) — request timeout in milliseconds.
- `GRAVITY_FORMS_MAX_RETRIES` (default `3`) — how many times a failed request is retried.
- `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 the request method, a sanitized URL, the response status, and which authentication method was selected. Request and response bodies are not written to the log, so your form and entry contents stay out of it, and secrets appearing in URLs or headers are masked.

## 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 set `GRAVITY_FORMS_ALLOW_HTTP_BASIC_AUTH=true`, which also 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, and feeds

Deletion is off by default. With `GRAVITY_FORMS_ALLOW_DELETE` unset or `false`, `gf_delete_form`, `gf_delete_entry`, and `gf_delete_feed` 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.

## Local development

Local environments such as Laravel Valet, MAMP, and Local WP use self-signed SSL certificates, which the server rejects by default. Add this to the `env` block to accept them:

```
"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 tools published by your GravityKit products. Those reach the same site over the WordPress REST Abilities API, so on a single install they need no extra configuration — they reuse your `GRAVITY_FORMS_*` credentials, which must 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`.

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.

## Pointing the server at a test site

You can keep a second set of credentials alongside your live ones and switch between them, which is useful while you are developing against the server:

```
GRAVITY_FORMS_TEST_BASE_URL=https://staging.yoursite.com
GRAVITY_FORMS_TEST_CONSUMER_KEY=ck_test_key
GRAVITY_FORMS_TEST_CONSUMER_SECRET=cs_test_secret
GRAVITYKIT_MCP_TEST_MODE=true
```

With `GRAVITYKIT_MCP_TEST_MODE=true` (or `NODE_ENV=test`), the `GRAVITY_FORMS_TEST_*` values replace their live equivalents and the server connects to the test site instead. The repository's test scripts also use this: they refuse to run against production credentials by default, and forms they create are prefixed `TEST_` so they are easy to find and clean up.

The full list of settings, including the ones used only by the test suite, is in `.env.example` in the [GravityKit MCP repository](https://github.com/GravityKit/MCP).