0 items
Sign in
Buy

Docs

GravityKit MCP configuration settings

Estimated reading: 3 minutes

Updated on August 17, 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, 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.

Was this page helpful?

Table Of Contents