AI tools (MCP server)

Grove ships a built-in Model Context Protocol server, so AI tools like Claude and Cursor can see your local environment and answer questions about it — live. Because Grove already knows your sites, proxies every request, and can read each project's database, it can hand an AI assistant a rich, accurate picture of what's actually running on your machine, with zero per-project setup.

It's read-only and runs entirely on your machine — nothing is sent anywhere except to the AI client you connect.

Start it

grove mcp

That runs an MCP server over stdio (newline-delimited JSON-RPC). You normally don't run it by hand — your AI client launches it for you.

Connect your client

Claude Desktop — edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "grove": { "command": "grove", "args": ["mcp"] }
  }
}

Cursor — add an MCP server in settings, or .cursor/mcp.json:

{
  "mcpServers": {
    "grove": { "command": "grove", "args": ["mcp"] }
  }
}

If grove isn't on your PATH, use the full path to the binary (for the desktop app that's /Applications/Grove.app/Contents/MacOS/grove, or install the shims with grove path install so grove resolves everywhere). Restart the client after editing its config.

What the AI can do

What is redacted

Grove is the proxy, so it sees every request in full. Anything these tools hand back has its credentials replaced with [redacted] first:

• Headers — Authorization, Cookie, Proxy-Authorization, X-Api-Key and any header whose name contains token, secret, password, api-key, credential or private-key.
• Query parameters and body fields with those same names, in JSON and form-encoded bodies. JSON is re-serialised, so the result is still valid JSON.

Names are kept, only values are replaced — a request that carried an Authorization header still looks like one.

Two limits worth knowing:

• A body Grove cannot parse (multipart, protobuf, something truncated mid-token) is passed through untouched. Redaction narrows the exposure; it does not eliminate it.
• Webhook signatures (Stripe-Signature, X-Hub-Signature) are not redacted. They authenticate a payload rather than granting access, and they are usually the thing you are debugging when you look at a webhook.

grove replay and grove hooks replay are unaffected: they use a separate in-process path that keeps the real credentials, or the replayed request would not be the same request.

So you can ask your assistant things like:

• "What routes does myapp have a controller for, and what did the last 500 error there look like?"
• "Show me the schema for the orders table in shop."
• "Show me the full chain for request #42 — how many queries did it run and did it send any email?" (turn on grove sql-capture on first for SQL)
• "Explain request #42 — why did it 500?" (uses grove_explain to pull the request, its queries, and the stacktrace together)
• "How many users signed up today?" (it runs a SELECT for you)
• "What webhook did Stripe just send, and did my handler 200?"

Agent-safe write tools (opt-in)

By default the server is read-only. Start it with --allow-write to expose tools that can change state — each one wrapped in a safety net so an agent can never leave your database in a broken state:

grove mcp --allow-write

Both support MySQL, PostgreSQL and SQLite.

How grove_migrate_sandboxed works:

1. Grove takes a point-in-time snapshot of the site's database first.
2. It runs the migration and captures the schema diff (added/removed tables and columns).
3. If the command fails, Grove automatically rolls back to the snapshot — your data is untouched.
4. Pass roll_back: true for a pure dry run: it runs, reports what the migration would change, then rolls back even on success.
5. On success it keeps the change and returns the snapshot_id so you can roll back manually at any time.

Works with MySQL, PostgreSQL (snapshotted via Grove's daemon) and SQLite (snapshotted by copying the .sqlite file). Every write operation is appended to an audit log at $GROVE_HOME/logs/mcp-writes.log (what ran, when, the snapshot id, and the outcome).

grove_sql_sandboxed follows the exact same snapshot → run → diff → rollback flow for a single write statement, returning rows_affected alongside the schema diff.

Both sandboxed write tools also return a chain — the SQL the operation actually ran and any mail it sent, correlated to the operation's time window (the same causal-chain shape used for requests). This is the blast radius: you can see everything a migration touched before deciding to keep it. Grove turns on SQL capture for the duration of the operation automatically (MySQL) and restores your previous capture setting afterwards.

So you can safely ask: "Add the migration for the invoices table and apply it", "Do a dry run of migrate:fresh and show me what tables it would create," or "Backfill users.status to 'active' where it's null — but roll back so I can review first."

Sandboxes: a whole running copy to work in

The snapshot tools protect your database while an agent changes it. A sandbox goes further: the agent never touches your checkout or your database at all.

grove_sandbox_open returns the sandbox's own site name, and every other tool takes it: grove_db_query, grove_requests, grove_request_chain, grove_logs, grove_migrate_sandboxed. So the agent edits files under the returned path, runs its migrations through Grove, and then looks at what the running app actually did against its own data, not just at its diff:

{
  "site": "myapp--agent-add-notes",
  "branch": "agent/add-notes",
  "url": "https://myapp--agent-add-notes.test",
  "path": "~/.grove/try/myapp/agent-add-notes",
  "database": {"engine": "mysql", "name": "myapp__gt_929546f2"}
}

Nothing reaches your checkout until you merge the branch. A sandbox is the same thing as grove try, so grove try --list shows the agent's sandboxes too, and grove try --done <branch> closes one by hand. Opening and closing are logged to mcp-writes.log like every other write.

Safety

• Read-only by default. Write tools appear only with grove mcp --allow-write, and even then the server refuses them if the flag is off.
• Sandboxed writes. Every write goes through a snapshot with automatic rollback on failure, plus an audit log.
• grove_db_query refuses anything that isn't a SELECT / SHOW / EXPLAIN / PRAGMA.
• Local only. The server talks to Grove's local daemon and your local databases; it makes no outbound network calls.
• Requires the Grove daemon to be running (grove start).

See also: Commands · Request timeline.