Gemini CLI 'Missing issuer parameter' 400: what Sume's OAuth sends

Gemini CLI answers HTTP 400 Missing issuer parameter in response when an authorization callback has no iss value and the CLI expected one. Sume's authorization redirect adds code and state and nothing else, and its authorization-server metadata does not set authorization_response_iss_parameter_supported. Under the MCP draft specification, that combination (flag absent, iss absent) is the one a client should accept, so a spec-following client proceeds. Gemini's own page is stricter in wording, so test your install before you rely on it.

This post separates three things: what Gemini CLI documents, what the MCP authorization draft requires of clients, and what Sume's OAuth flow sends. All were read on 2026-10-03.

What does Gemini CLI check?

Gemini CLI's MCP page has a section on authorization server requirements under RFC 9207. It says that to protect against identity-provider mix-up attacks the CLI validates the iss parameter, and that when an expected issuer is discovered or configured, authorization servers must return iss in the callback redirect, matching the issuer URL. A response missing iss is rejected with HTTP 400 Missing issuer parameter in response; one whose iss points at another domain is rejected with Issuer mismatch.

The page does not say whether an issuer discovered from metadata counts as expected when the server never advertises iss support. That sentence is the open question for a server like Sume's.

What does the MCP specification tell clients to do?

The draft authorization page says authorization servers SHOULD include iss, and a server that does MUST advertise it by setting authorization_response_iss_parameter_supported to true. It then gives clients a four-row rule, which is the part that matters here.

It adds that a future revision is expected to raise the server's iss from SHOULD to MUST, and that until then a client's rejection of a missing iss stays keyed on the advertisement flag.

Where does Sume fall in that table?

In the last row. Sume's published authorization-server metadata lists issuer, authorization_endpoint, token_endpoint, revocation_endpoint, registration_endpoint, the code response type, the authorization_code grant, S256 PKCE, public-client auth method none and the mcp:read and mcp:write scopes. It does not list the iss flag. The redirect built after consent sets code and state, and for a denial error=access_denied and state.

So a client following the draft proceeds. If your Gemini CLI build does reject the callback, the message above is what you will see, and the page does not document a setting that turns the check off. Use the API-key path from OAuth and API keys meanwhile: send Authorization: Bearer <key> or x-api-key, which needs no browser callback at all.

How do I test it in two minutes?

Add the server as a remote entry, run the CLI's OAuth command for it and watch whether the callback completes. Gemini's page says to use /mcp auth to manage OAuth, and that discovery runs when a server answers 401. After a successful sign-in, ask the model to call mcp_health, which Sume's tool list describes as a read-only readiness check.

If it fails with the issuer message, keep the exact text and the CLI version; that report is more useful to both projects than a guess. Note the browser requirement too: Gemini's page says the OAuth flow does not work in headless environments, remote SSH sessions without X11 forwarding, or containers without browser support.

{
  "mcpServers": {
    "sume": {
      "httpUrl": "https://mcp.sume.com/mcp"
    }
  }
}

What should I send upstream if it fails?

Three things: the CLI version, the exact error text, and the metadata document the CLI discovered. Fetch https://mcp.sume.com/.well-known/oauth-authorization-server and attach it; it shows the issuer the CLI recorded and the absence of the iss flag. With that, either project can say whether the CLI is applying the draft's four-row rule or its own stricter one.

Until it is settled, a key is the dependable route for scripts, and OAuth stays the better route for people because Write is a visible toggle. Both reach the same tools; the difference is what the session can do before anyone looks.