> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gravitygtm.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Self-serve configuration: managing your agents through Claude.ai or ChatGPT

> Connect the Gravity Agents Lite config MCP server to Claude.ai or ChatGPT to manage your settings and, for new customers, complete onboarding — all through a real OAuth flow, no shared API keys.

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.

<Note>
  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`.
</Note>

<Tip>
  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](/agents-lite/bring-your-own-oauth).
</Tip>

<Tip>
  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.
</Tip>

## 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.

<Note>
  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).
</Note>

## 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:

| Tool                       | What it does                                                                                                                                                                               |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `get_onboarding_status`    | Your current onboarding phase, a section-by-section completeness summary (team, north star, tool stack, modules, routing, content, infra), and the full current list of validation issues. |
| `onboarding_next_step`     | Tells you exactly what to fill in next, in order, surfacing the valid option keys for each choice and *why* a given step matters (which module needs it).                                  |
| `submit_onboarding_answer` | Sets one field of your draft configuration to a new value — rejects an unknown field or an invalid option immediately, before it's saved.                                                  |
| `submit_for_review`        | Re-validates your entire draft. Zero errors flips your status to "submitted" and hands off to Gravity for provisioning; any errors come back as a specific list, with nothing advanced.    |

Onboarding tools never ask for a secret directly — any credential your
deployment needs is collected separately, through a dedicated hosted page
(see [Security & credentials](/agents-lite/security-and-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:

| Tool                          | What it does                                                                                                                                                                                                                                                                      |
| ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `get_config`                  | Your current value for every field this server knows about — never your raw configuration file, and never internal-routing fields (those stay permanently read-only). Founder identity is no longer excluded here either — adding and removing a founder is self-service now too. |
| `describe_config_options`     | Every configuration field, grouped by domain: its type, bounds, whether it's currently editable, and why, for anything read-only.                                                                                                                                                 |
| `preview_change`              | Validates a proposed value against every rule that applies (type, bounds, cross-field checks, any operator-set ceiling) and shows the would-be diff — a dry run that never writes anything.                                                                                       |
| `update_config`               | The same validation as `preview_change`, and if it passes, commits the change with an audit-trail entry. Requires a short reason for the change.                                                                                                                                  |
| `get_change_history`          | Your recent configuration changes, accepted and rejected, most recent first.                                                                                                                                                                                                      |
| `revert_last_change`          | Undoes your most recent `update_config` change, back to what it was immediately before. Single-level undo only — calling it twice in a row undoes the undo. The schedule-specific `revert_last_schedule_change` below is the same idea, scoped to schedules instead.              |
| `get_schedules`               | Your real, currently-deployed run schedule for every agent — day/time (UTC) or run interval, read live from your own deployment, including whether an agent is currently paused. Free.                                                                                            |
| `preview_schedule_change`     | For the 6 schedule-editable agents: validates a proposed new day/time or run interval against your real deployment and a safe frequency floor, and shows what it would look like. Never writes anything — a dry run. Free.                                                        |
| `update_schedule`             | The same validation as `preview_schedule_change`, and if it passes, commits the new schedule with an audit-trail entry. Requires a short reason. Backup run times (for agents that have any) are always recomputed automatically — never something you specify directly.          |
| `pause_schedule`              | Fully stops any one of your agents from running, until you resume it — works for every agent, including the handful not editable for day/time changes. Requires a short reason. Calling it again while already paused is a harmless no-op.                                        |
| `resume_schedule`             | Restores a paused agent's normal schedule exactly as it was before the pause — re-checked against your current frequency limits first, in case one was tightened while paused. Requires a short reason.                                                                           |
| `revert_last_schedule_change` | Undoes your most recent `update_schedule` change for one agent, back to what it was immediately before. Single-level undo only — calling it twice in a row undoes the undo. Blocked while an agent is paused.                                                                     |

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](/agents-lite/security-and-credentials) for how
this fits into the full credential story across your deployment.

## Next steps

* [Security & credentials](/agents-lite/security-and-credentials) — the
  full trust model for every secret involved
* [Available integrations & modules](/agents-lite/integrations-and-modules) —
  the registry of everything you can configure
* [Agent reference](/agents-lite/agent-reference) — exactly which of these
  fields each module actually reads, module by module
* [Getting started](/agents-lite/getting-started) — the full onboarding
  conversation this connector drives, and what happens after you submit it
* [Onboarding reference](/agents-lite/onboarding-reference) — the precise,
  field-by-field detail behind the onboarding tools described above