## Problem Gemini CLI fails to authenticate to the Orbit MCP endpoint using its native HTTP transport (`httpUrl` config). Claude Code works because it negotiates the OAuth scope automatically. Surfaced by a real customer (Carrefour) in #f_orbit_dev. Customer config that failed: ```json "gitlab-orbit": { "httpUrl": "https://gitlab.com/api/v4/orbit/mcp", "timeout": 5000 } ``` ## Root cause Clients on the native HTTP MCP transport must explicitly request the `mcp_orbit` OAuth scope. Without it, auth fails. Verified fix (Dmitry Gruzd): ```json { "mcpServers": { "gitlab-orbit": { "url": "https://gitlab.com/api/v4/orbit/mcp", "type": "http", "timeout": 5000, "oauth": { "enabled": true, "scopes": ["mcp_orbit"] } } } } ``` ## Docs gap In `docs/source/remote/access/mcp.md`: - Gemini CLI is listed as a supported client but has no config example. - Every JSON example routes through the `npx mcp-remote` wrapper. None show the native HTTP path, so the `oauth.scopes` requirement is documented nowhere. - The `mcp_orbit` OAuth scope is never mentioned. Prerequisites only cover `read_api` for PATs. ## Proposed fix - Add a Gemini CLI subsection with the verified native-HTTP config including `oauth.scopes: ["mcp_orbit"]`. - Add a troubleshooting note: if a client uses native HTTP transport and auth fails, add `oauth.scopes: ["mcp_orbit"]` to the server config. - Confirm the correct Gemini config key (`url` + `type` vs `httpUrl`) before merging. ## Why now Auth/403 failures are on the June 10 launch punch list. This is a real customer hitting it during beta. Low effort, high impact for field and design partners.