Skip to main content
Once your agent fleet is deployed, day-to-day tuning of the fields this server exposes — your ICP and voice/content settings, discovery and sending volumes, routing defaults, and more — doesn’t require a support ticket or a code change. A dedicated config MCP (Model Context Protocol) server exposes a small, reviewed set of tools that your own Claude.ai or ChatGPT session can call directly, on your behalf, to read and adjust your configuration.
Not everything is editable here yet. Slack channel routing stays permanently read-only through this server; ask Gravity for that change today. Per-agent run schedules are now real, live editable for 6 agents — Email Follow-up, GTM Signal Capture, Market Intelligence, Fundraising Digest, LinkedIn Engagement, and PR Outreach — via preview_schedule_change/update_schedule below. A few multi-mode agents (Investor Relations, Company Clarity) and a multi-attempt one (Meeting Prep) still can’t have their cadence reshaped this way; ask Gravity for those changes today. Every agent, including those three, CAN be fully paused and resumed on demand (pause_schedule/ resume_schedule), and a schedule change can be undone with revert_last_schedule_change — see below for all five. You can also always see your real, currently-deployed run schedule — ask your connected agent “what’s my schedule?” (get_schedules, listed below). A non-schedule configuration change gets the same single-level undo — revert_last_change, also described below, alongside update_config.
Google Workspace customers can connect Gmail/Calendar/Drive through their own Google Cloud OAuth app instead of Gravity’s — takes effect immediately, no waiting. See Bring your own OAuth app.
This is a genuinely different surface from the agents themselves. The agents read your inbox, calendar, and pipeline to do GTM work; the config MCP server only reads and writes your settings — it never touches your email, your contacts, or your pipeline data.

​
Connecting it

The config server connects to Claude.ai (or another OAuth-aware MCP client, e.g. ChatGPT) as a custom connector, the same way you’d add any other remote MCP server — there’s no API key to copy-paste out of band. Adding the connector’s URL kicks off a real, spec-correct OAuth authorization flow:
  1. You’re prompted to authorize the connection in your browser.
  2. A short setup code (delivered to you by Gravity when your deployment is created) identifies which customer’s configuration this connection is for. It’s reusable on purpose, not single-use — see the note below.
  3. Approving the flow mints a credential scoped to your configuration only — never a shared key, and never something you paste into a chat message.
From that point on, your Claude.ai or ChatGPT session can call the tools below directly, and every call is authenticated as you.
Your setup code stays valid for reconnects — losing access to a client, connecting a second one (say, both Claude.ai and ChatGPT), or rotating your underlying credential all just mean presenting the same code again. It rotates your connection’s credential each time rather than stacking up unlimited separate ones. The only thing that invalidates it is Gravity explicitly revoking it on your behalf (for example, if you offboard).

​
The two kinds of tools

​
Onboarding tools — for a brand-new deployment

If your deployment hasn’t gone live yet, the connector starts you in onboarding mode. Four tools walk you through building up your configuration section by section, with real validation at each step so a mistake gets caught immediately rather than at go-live: Onboarding tools never ask for a secret directly — any credential your deployment needs is collected separately, through a dedicated hosted page (see Security & credentials). Once your infrastructure is actually provisioned, an operator links your onboarding record to your real deployment — at that point, re-authorize once more with the same setup code (a quick repeat of step 1 above, not a new connector or a new code), and that reconnection is what upgrades your credential to the ongoing config tools below. Until you do that reconnect, your existing connection still only has the onboarding tools.

​
Config tools — for an already-live deployment

Once you’re live, five tools cover ongoing, day-to-day tuning: A handful of fields stay permanently read-only regardless of mode — tokens and Slack channel IDs chief among them — and a few fields can only be turned down, never up, without an operator’s involvement (for example, anything that gates actual send volume). As of 2026-08-14, founder identity is no longer in that read-only bucket — adding and removing a founder is self-service through this same server now, the same as any other field. Calling describe_config_options always tells you which fields are which, and why, rather than leaving you to guess.

​
The trust model

  • Every secret goes through a hosted, encrypted page — never through chat. Neither the onboarding tools nor the config tools ever ask you to paste a credential into a message; anything sensitive is collected through a dedicated form and encrypted at rest immediately.
  • Nothing is logged in plaintext. Config values you set through these tools are ordinary settings (an ICP threshold, a piece of voice/content copy, a sending volume) — not secrets — and are recorded in your change history for transparency. Actual credentials never flow through this path at all.
  • Config changes are always customer-initiated. Every write is tied to your own authenticated connection and requires a stated reason, which is recorded whether the change is accepted or rejected.
  • Unknown or sensitive fields fail closed. A field this server doesn’t recognize, or one that’s marked read-only, is rejected outright rather than silently ignored or guessed at.
See Security & credentials for how this fits into the full credential story across your deployment.

​
Next steps