Zed context_servers for the hosted Sume server: no header means OAuth

In Zed, add the hosted Sume server under context_servers in settings.json with a url of https://mcp.sume.com/mcp and no headers; Zed then runs the MCP OAuth flow for you. The Zed MCP documentation (read 2026-10-06) describes context_servers.<name> with url and optional headers, and says that when no Authorization header is set Zed starts OAuth. For Sume that is the safe default, since the hosted OAuth grant is read-only unless you opt in to writes.

If you do want an API key instead, add an Authorization header and Zed skips OAuth.

What does OAuth give me in Zed?

Per Sume hosted OAuth and API keys, the supported scopes are mcp:read, which is required, and mcp:write, which is opt-in at the consent page. There is no mcp:paid scope: paid submits are governed by wallet and admission, and paid and write tools need an idempotency_key. A read-only session can still list tools, read jobs and fetch assets, and a write or paid call returns insufficient_scope. That is a useful rail while you are learning what the agent does.

What does the settings entry look like?

import json

oauth = json.loads("""{
  "context_servers": {
    "sume": {"url": "https://mcp.sume.com/mcp"}
  }
}""")
keyed = json.loads("""{
  "context_servers": {
    "sume": {"url": "https://mcp.sume.com/mcp",
             "headers": {"Authorization": "Bearer YOUR_KEY"}}
  }
}""")

def mode(cfg):
    s = cfg["context_servers"]["sume"]
    assert s["url"] == "https://mcp.sume.com/mcp"
    has = any(k.lower() == "authorization" for k in s.get("headers", {}))
    return "api-key" if has else "oauth"

assert mode(oauth) == "oauth" and mode(keyed) == "api-key"
print("zed modes ok:", mode(oauth), mode(keyed))

What happens on long jobs?

Verify the same way as in the other editors. Open the agent panel, confirm the server shows as connected, and ask for tools_list or mcp_health. If a later request is slow, remember that jobs_wait holds for 50 seconds by default and 55 at most, so a long video needs repeated waits on the same job ids. A wait_slice_expired result means the job is still running, and a 522 to 525 error is a transport problem, not a verdict on the job. Never repeat the create call to recover; look the job up with jobs_status first.

When you move from reading to writing, sign in again with Write on and ask for a dry_run first. Treat the key header option as a last resort for headless setups, since it carries full access and lives in a file on disk.

The choice between the two entries is mostly about who is at the keyboard. An interactive developer should use the url-only entry and click through consent once, because the grant is tied to their sign-in, can be revoked without touching a file, and stays read-only until they decide otherwise. A build machine or a remote development box with no browser is the case for the header form, and there the key should come from your secret store when the file is generated, not be typed by hand. In both cases the first call to make is mcp_health, which tells you which authentication source the session is using, so you can confirm that Zed did what you intended instead of assuming it. If the status shows a sign-in needed after a restart, repeat the consent rather than switching to a key, and if you change the scope later, expect to consent again, since the grant is what carries the permission. Keep a note of which of your machines use which mode; mixing the two across a team is fine, but only if each person knows which one they have.