Gemini CLI MCP OAuth metadata discovery blocked: Sume check
Gemini CLI v0.59.0 added SSRF prevention to MCP OAuth metadata discovery. Sume publishes metadata at two public HTTPS URLs; how to confirm both from a shell.
If Gemini CLI blocks MCP OAuth metadata discovery for Sume, first make sure the client is pointed at the public Sume endpoint and that both metadata documents answer over public HTTPS. Gemini CLI v0.59.0 (2026-09-08) added SSRF prevention to that discovery step, and Sume's metadata lives on public URLs under mcp.sume.com, so a correct setup has nothing private for the client to reach.
The Gemini CLI change is quoted from its changelog, read 2026-09-29. The changelog does not list which addresses it refuses, so this post makes no claim about that; it covers what Sume publishes and how to check it.
What does the Gemini CLI change say?
The changelog line for v0.59.0 reads that it prevented SSRF during MCP OAuth metadata discovery. Discovery is the step where a client fetches the server's protected-resource and authorization-server metadata before sending you to sign in.
Which Sume URLs does discovery touch?
Sume's OAuth docs list two public metadata endpoints and one resource audience.
| Purpose | URL |
|---|---|
| Protected-resource metadata | https://mcp.sume.com/.well-known/oauth-protected-resource/mcp |
| Authorization-server metadata | https://mcp.sume.com/.well-known/oauth-authorization-server |
| Resource audience | https://mcp.sume.com/mcp |
How do I check both endpoints from a shell?
Fetch both documents with curl from the machine that runs Gemini CLI. If either fails there, the problem is your network path (a proxy, DNS override or VPN), not the client's discovery logic. If both answer, the MCP server entry in your config is the next thing to read.
curl -sS https://mcp.sume.com/.well-known/oauth-protected-resource/mcp
curl -sS https://mcp.sume.com/.well-known/oauth-authorization-serverWhat should the server entry use?
Point a streamable HTTP MCP server at https://mcp.sume.com/mcp and run that client's OAuth login for the configured server name. The protected-resource metadata names authorization_servers as the MCP origin, not www or app.sume.com, and interactive clients should not be sent to app.sume.com for MCP OAuth. Details are in OAuth and API keys.
What if a client still cannot finish OAuth?
API-key remote MCP remains the other path for automation that does not speak OAuth: send Authorization: Bearer $SUME_API_KEY or an x-api-key header. Keep in mind that API-key sessions can see write and paid tools, and that an MCP OAuth token is not a Sume API key.
What should a working login look like?
After discovery the client sends you to https://mcp.sume.com/oauth/authorize, which redirects to the first-party consent page on the MCP host. Consent shows Permissions with Read locked on and the Write toggle off by default. The client then exchanges the authorization code (PKCE) for an access token and calls https://mcp.sume.com/mcp with that bearer token.
If your client gets as far as consent, discovery worked and any block you see is somewhere else in the chain.
Sources
Related posts
More in Developers
- Golang HTTP client retry: what net/http retries on POST
Go's http.Transport retries only network errors on reused connections, and a POST only with an Idempotency-Key header. Write the 429 and 5xx loop yourself.
- GPT-6 Astra tool calling needs the Responses API: meaning for Sume
OpenAI says GPT-6 Astra supports Chat Completions but its tool calling requires Responses. Use the Responses mcp tool for Sume, not a chat.completions loop.
- How long does GPT Image 2.5 take? Time your own jobs on Sume
Sume publishes no per-model image time for GPT Image 2.5, only a 30-second wait budget. A short curl script times your own prompts by quality and size.
- GPT Image 2.5 arena: run your own blind test through the API
Arena leaderboards rank images on other people's prompts. Here is a blind three-way test of Flare, Sunburst and GPT Image 2 on yours, with one script on Sume.
Written by Sume