Sume MCP config keys in Cline, Zed, Gemini CLI and Zapier

Every client points at the same address, https://mcp.sume.com/mcp, but each names the field differently: Cline uses type streamableHttp plus url, Zed uses url under context_servers, Gemini CLI uses httpUrl (its url key means SSE), and Zapier's MCP Client form asks for a server URL and a transport. This page lines them up so you can copy the right key.

What does each client call the field?

The table is built from each vendor's own page, read on the date in the caption.

What happens when you send no key?

Zed's docs say that when no Authorization header is configured, Zed prompts you to authenticate through the standard MCP OAuth flow. Sume supports that flow: it answers with protected-resource metadata, sends you to its consent page on the MCP host, and issues a token. The default is read-only (mcp:read); the Write toggle adds mcp:write.

Gemini CLI defaults to dynamic discovery for its OAuth provider type, and Zapier has an OAuth option on the form. Cline's page documents headers and a CLI wizard for browser authorization.

Which credential suits which job?

A Sume OAuth token is not a Sume API key, and neither replaces the other. Do not paste either into chat.

• Exploring a catalog from an editor: OAuth, Write off.
• Generating media from an editor: OAuth with Write on, or a key.
• Unattended automation such as Zapier or CI: an API key.
• Anything paid: send dry_run true first, plus an idempotency_key.

What stays the same in every client?

Whatever the field name, the server behavior does not change. The URL is the production hosted endpoint, discovery tools are free, and the first call worth making is mcp_health followed by tools_list. Write and paid tools always need an idempotency_key, and dry_run previews a cost without submitting.

Do not put the key in the URL. Sume documents the Authorization bearer header and the x-api-key header for key sessions, and the vendor pages above show a header object or a bearer token field in each client. Where a client cannot hide the key in a header, use OAuth instead.

If a client reports a failed connection, compare the URL spelling character by character against https://mcp.sume.com/mcp, then check the transport field. Choosing SSE where Streamable HTTP is expected is the most common mismatch.

Before you rely on any of this in a team setting, test it once end to end with a throwaway prompt. Call mcp_health, call tools_list, and run one dry_run against a paid tool. Compare the tool count with what you expected for your credential. If a read-only OAuth session lists more than you expected, or a key session lists fewer, stop and recheck which credential the client is actually sending. Sume's mcp_health response reports the auth source, which settles the question quickly without guessing.