Migrate Gemini CLI to Antigravity CLI for WordPress MCP

Migrate Gemini CLI to Antigravity CLI without losing the WordPress server

Gemini CLI kept MCP servers inline in ~/.gemini/settings.json. Antigravity CLI, which you run as agy, reads them from a separate file instead: ~/.gemini/config/mcp_config.json for every project, or .agents/mcp_config.json inside one workspace. Nothing reads the old block any more, so a WordPress server that worked yesterday simply is not there after the switch, with no error to say why.

Google's migration guide offers an importer, agy plugin import gemini, which converts legacy Gemini extensions and moves MCP server definitions into mcp_config.json. Run it if you used extensions, then open the resulting file and inspect the WordPress entry by hand, because the importer does not make the credential decisions below for you. Two other things move manually or not at all: workspace skills must be moved from .gemini/skills/ to .agents/skills/ to be recognised, while GEMINI.md and AGENTS.md workspace rules carry over unchanged.

Treat the move as a new connection rather than a file copy. Open GoBuildWP, Connect a client, choose Antigravity CLI in Step 2, and compare what it generates with what the importer wrote. Where they differ, the generated entry is the one built for the client you now use.

• Copy the old mcpServers block out of ~/.gemini/settings.json for reference
• Choose global or workspace scope for the new entry
• Run agy plugin import gemini if you relied on extensions
• Move workspace skills to .agents/skills/
• Replace the WordPress entry with the one Connect a client generates

Old entry, new entry: what changes in the file

The server entry keeps the same outer shape, an mcpServers object with one named server, which is why an old entry looks right at a glance. The key that holds the address is what changed, and Google's documentation says the legacy keys are not supported.

• httpUrl becomes serverUrl. This is the one that catches most WordPress setups, because Gemini CLI guides used httpUrl for remote servers.
• url becomes serverUrl as well.
• An access-token connection keeps its headers object beside serverUrl, with the Authorization value GoBuildWP generated.
• An Application Password connection is not a remote entry at all: GoBuildWP generates a command entry that runs the npx mcp-remote bridge, with the credentials in env.
• An OAuth connection is serverUrl alone. Antigravity signs in again on first use and keeps its own tokens, so nothing from Gemini CLI's sign-in is reused.

Retire the Gemini CLI credential once agy works

Migrating a client does not revoke its old WordPress credentials. Review Gemini CLI's grant under Manage connected apps, Application Passwords on the user's profile and access tokens on Connect. OAuth tokens have their own lifetimes, Application Passwords remain until revoked, and GoBuildWP tokens follow their configured expiry. Revoke the old authorization deliberately after the replacement's required reads work.

Wait until agy has completed a read, then revoke the old one. Name the new credential after the client and machine, such as agy on the build server, so a later review can tell which entry belongs to which tool. If you are moving scripted jobs, an access token suits them better than a browser sign-in: Create access token lets you set an expiry of one, seven, thirty or ninety days, choose What this token may use (every ability the safety profile allows, or only chosen categories and abilities), and set a Safety profile ceiling below the site's own.

Set the review level again, on purpose

Approval habits are part of what you are migrating, even though no file holds them in the same form. Antigravity has its own permission layer: a toolPermission setting with four levels, request-review (the default), proceed-in-sandbox, always-proceed and strict, plus rules that let named tools run without asking. Start the WordPress server at request-review, so every WordPress tool call asks, and add rules only for reads you have watched run.

That layer decides whether agy calls a tool. It does not decide what the call may do on the site; GoBuildWP's safety profile, the WordPress user's capabilities and the confirmation setting still do that, and they apply whatever agy was told. For an unattended job, keep both layers narrow: a token limited to the abilities the job needs, and permission rules for exactly those tools.

A useful first prompt after the move: Use only the WordPress MCP server. Read only. List the abilities you can see, inspect the schema for wppilot/list-content, list one page and report the tool name, the page ID and any refusal. Compare the ability list with what Gemini CLI saw; a shorter list usually means a different credential or profile, not a broken migration.

When Gemini CLI stays in use

Gemini CLI still serves enterprise accounts and paid API keys, so some teams will run both clients for a while. That is workable if each client has its own entry and its own credential. Gemini CLI entries keep httpUrl, and GoBuildWP still generates that shape when Gemini CLI is the client you pick; do not paste one client's entry into the other's file.

Give each client a separate WordPress credential too. Then the Dashboard's AI clients list and the Changes screen show which client did what, and revoking one does not cut off the other.

Proving the migration worked

Check from both ends. In agy, /mcp should list the WordPress server with no error. On the site, reload Step 3 of Connect a client after agy's first call: it reports the clients that authenticated and introduced themselves, and Antigravity should now be among them. Then confirm the old connection has stopped: its last-used time on the Dashboard should no longer move.

If agy lists the server but every call fails, compare the two ends before editing again. A 401 that GoBuildWP's Diagnostics screen can explain is a credential or header problem on the site's side; a server that never reaches WordPress at all, with nothing new on the Dashboard, is still a configuration problem in mcp_config.json, most often a leftover httpUrl key or an entry saved in the .agents/mcp_config.json of a different workspace from the one agy is running in.

• /mcp in agy lists the server without an error
• Step 3 on Connect a client names the new client
• A Read Only read returns a named tool and an object ID
• No httpUrl or url keys left in mcp_config.json
• The Gemini CLI credential revoked, unless Gemini CLI is still in use