Gemini CLI httpUrl or url for Sume MCP: which key to use

Use httpUrl. The Gemini CLI docs define url as a Server-Sent Events endpoint and httpUrl as an HTTP streaming endpoint, and Sume's hosted server at https://mcp.sume.com/mcp speaks streamable HTTP over POST. Putting the Sume URL under url selects the wrong transport.

Settings entry

Add the server to the mcpServers object in Gemini CLI settings. The headers object takes custom HTTP headers, which is where an API key goes. Leave headers out if you plan to sign in with OAuth.

{
  "mcpServers": {
    "sume": {
      "httpUrl": "https://mcp.sume.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_SUME_API_KEY"
      },
      "timeout": 60000
    }
  }
}

What Sume expects

The Sume docs describe the endpoint as the production URL for remote MCP clients and say the protocol is streamable HTTP. A bare GET is not the way to talk to it; clients send JSON-RPC by POST.

Verify

Start Gemini CLI, list the servers and ask it to call tools_list. If the server shows as disconnected, the first thing to check is the key name: a server under url fails here for the transport reason above. If you use OAuth, complete the sign-in on the MCP host's consent page, not on app.sume.com.

Symptoms of the wrong key

If the Sume URL is under url, Gemini CLI tries to open an event stream to a server that expects JSON-RPC posts. You will usually see the server marked disconnected, with no tools discovered. Moving the same URL to httpUrl fixes it without any server change.

Auth choices

Use headers for an API key. That session sees the full tool set, so pair it with includeTools if the agent should only read. For OAuth, omit headers and complete the sign-in; the session is read-only unless Write was turned on at the consent page. Do not mix both in one entry, since Sume treats an OAuth token and an API key as separate credentials and one cannot replace the other.

If you share settings across a team, put the entry in a project settings file and keep keys out of it. Each person can use OAuth, which needs no shared secret, and every sign-in is tied to that person's own workspace access. Check the protocol too: Sume lists support for the 2025-03-26, 2025-06-18 and 2025-11-25 versions and declares tools only, so a client that expects resources or prompts from this server will find none. That is normal, and the tool list is the whole surface.

Before you rely on this setup, run a short acceptance test with a read-only credential. Connect, call mcp_health, call tools_list, and read one job with jobs_status. Record the tool count you see, so you can notice later if a credential change alters it. Then repeat the test after any config edit. A five-minute test like this catches most wiring mistakes before they cost money, and it gives you a baseline to compare against when something behaves differently next week.