Summary
The Gong plugin's documented setup can't be completed on desktop. third_party/gong/README.md step 2 tells admins to register http://localhost:8787/callback as a redirect URI on the Gong MCP integration, but Gong's admin API refuses to store any http:// redirect URI. Since that URI can never be whitelisted, desktop OAuth always ends in unauthorized_client.
Error
After clicking ALLOW on Gong's consent screen, the browser lands on:
http://localhost:8787/callback?error=unauthorized_client&error_description=This%20MCP%20client%20is%20not%20authorized%20for%20your%20company.%20Please%20ask%20your%20Gong%20technical%20admin%20to%20authorize%20it.
The message points at the admin, which sends people hunting for an approval setting that doesn't exist. The real cause is the redirect URI.
Why the documented step can't be done
Gong's Redirect URL field accepts https:// only:
- Saving
http://localhost:8787/callback → the admin API PUT returns 400 Bad Request; on a retry the line is silently dropped from the saved list.
- The same field saves
https:// URIs without complaint — including https://localhost:<port>/oauth/callback and the Cursor web callback already in the README.
So the scheme is what's rejected, not loopback itself.
Isolation
Same Gong integration, same client ID and secret, changing one variable at a time:
| Redirect URI |
Scopes |
Result |
https://<whitelisted-https-host>:<port>/oauth/callback |
mcp:read |
access token issued |
http://localhost:8787/callback |
mcp:read mcp:write + resource |
unauthorized_client |
http://localhost:8787/callback |
mcp:read |
unauthorized_client |
Scopes and the resource parameter make no difference. Only the redirect URI does.
One detail that makes this painful to diagnose: Gong renders the consent screen before validating the redirect URI. The flow looks healthy — the app name, the requested scopes, everything — right up until you click ALLOW. Only then does it reject. It's easy to conclude the callback is fine and go looking elsewhere.
Tested against both a Personal access and a Shared access integration, both Manual registration. Same result.
Suggested fixes
- Use an
https loopback callback for desktop, or route desktop through the same https://www.cursor.com/agents/mcp/oauth/callback that Web and Cloud Agents already use.
- At minimum, update
third_party/gong/README.md so admins aren't asked to register a URI that Gong won't accept.
RFC 8252 §7.3 expects native apps to use loopback redirects, so this is arguably worth raising with Gong as well — but as things stand their admin API rejects http://, so the plugin can't depend on it.
Environment
- Gong MCP server:
https://mcp.gong.io/mcp
- Integration: Manual registration (client ID + secret)
- Plugin:
third_party/gong 1.0.0
Summary
The Gong plugin's documented setup can't be completed on desktop.
third_party/gong/README.mdstep 2 tells admins to registerhttp://localhost:8787/callbackas a redirect URI on the Gong MCP integration, but Gong's admin API refuses to store anyhttp://redirect URI. Since that URI can never be whitelisted, desktop OAuth always ends inunauthorized_client.Error
After clicking ALLOW on Gong's consent screen, the browser lands on:
The message points at the admin, which sends people hunting for an approval setting that doesn't exist. The real cause is the redirect URI.
Why the documented step can't be done
Gong's Redirect URL field accepts
https://only:http://localhost:8787/callback→ the admin APIPUTreturns400 Bad Request; on a retry the line is silently dropped from the saved list.https://URIs without complaint — includinghttps://localhost:<port>/oauth/callbackand the Cursor web callback already in the README.So the scheme is what's rejected, not loopback itself.
Isolation
Same Gong integration, same client ID and secret, changing one variable at a time:
https://<whitelisted-https-host>:<port>/oauth/callbackmcp:readhttp://localhost:8787/callbackmcp:read mcp:write+resourceunauthorized_clienthttp://localhost:8787/callbackmcp:readunauthorized_clientScopes and the
resourceparameter make no difference. Only the redirect URI does.One detail that makes this painful to diagnose: Gong renders the consent screen before validating the redirect URI. The flow looks healthy — the app name, the requested scopes, everything — right up until you click ALLOW. Only then does it reject. It's easy to conclude the callback is fine and go looking elsewhere.
Tested against both a Personal access and a Shared access integration, both Manual registration. Same result.
Suggested fixes
httpsloopback callback for desktop, or route desktop through the samehttps://www.cursor.com/agents/mcp/oauth/callbackthat Web and Cloud Agents already use.third_party/gong/README.mdso admins aren't asked to register a URI that Gong won't accept.RFC 8252 §7.3 expects native apps to use loopback redirects, so this is arguably worth raising with Gong as well — but as things stand their admin API rejects
http://, so the plugin can't depend on it.Environment
https://mcp.gong.io/mcpthird_party/gong1.0.0