DocumentationConnect Google Antigravity to Rivul Atlas
Public guide
Connect Google Antigravity to Rivul Atlas
An Atlas-specific Antigravity setup guide with the exact production blocker recorded during Authenticate and a safe cleanup and retest path.
On this page
Current status
Status: Blocked. The retained production attempt reached Google Antigravity's native Authenticate handoff, then Google's agentPlugins backend returned 404 before Atlas authorization could complete.
Rivul's discovery metadata was available, but no end-to-end Antigravity tool call was retained. This is a setup guide, not a verified compatibility claim. Retest when the vendor backend no longer returns 404.
Add Atlas to Antigravity
Open Agent Settings, Customizations, MCP Servers, then View raw config.
Add Rivul Atlas with serverUrl. Do not replace serverUrl with url or httpUrl.
Save the configuration, return to MCP Servers, and choose Authenticate next to Rivul Atlas.
{
"mcpServers": {
"rivul-atlas": {
"serverUrl": "https://rivul.ai/mcp"
}
}
}Complete and verify the handoff
When Authenticate opens Rivul, choose the intended workspace and approve the two read-only scopes.
If Rivul displays an authorization code, copy it back into Antigravity and submit it once.
Confirm search_papers and usage_status appear, then run a three-result search and a usage read. The retained attempt did not reach this point.
Handle the current 404 blocker
A 404 from Google's agentPlugins backend occurs inside Antigravity's vendor handoff, not at https://rivul.ai/mcp. Repeated consent attempts can create unused grants without changing that result.
Stop after one clean retry. Disconnect any temporary Antigravity grant in Rivul Atlas, remove the test server entry if it is no longer needed, and wait for the vendor backend to recover or the client to update.
Manual key boundary and official references
Antigravity documents custom headers for remote servers, but its guide does not promise environment-variable expansion inside those header values. Never put a real Atlas key in a committed workspace file. A private literal-key configuration is an optional fallback, not part of the retained verified evidence.
A future passing run must include both tools, bounded search, usage read, grant or key revocation, and denied access afterward.
Something here wrong or missing? Email support@rivul.ai.