MCP OAuth token expires: Sume's one-hour token, no refresh

Sume's hosted MCP OAuth access token expires after one hour, and the server does not offer a refresh grant, so when it lapses the client has to sign in again. In the OAuth package the access-token lifetime is a one-hour constant, the authorization-server metadata lists only the authorization_code grant, and the token response carries expires_in but no refresh_token. For a run that must outlast an hour, the docs' other path is an API key.

These facts are from the MCP OAuth package and token endpoint source, plus Sume's MCP OAuth and API keys page, read 2026-09-30.

What does the token endpoint return?

The token response contains access_token, token_type, expires_in and scope. There is no refresh_token field. A code comment in the OAuth package also says clients such as Cursor often advertise refresh_token, which the server ignores because refresh is not implemented yet. Treat that as the current state, not a promise.

How do I recover when the token expires?

Sign in again. In Claude Code that is the quickstart's claude mcp login sume. Claude Code has been fixing sign-in handling recently: its 2.1.286 changelog entry fixes a repeat MCP sign-in request replacing the pending sign-in link, which could stop that link from working. If a sign-in link seems dead, request it once and use it before asking again.

Which auth mode fits a long or unattended run?

The docs say API-key remote MCP remains the path for automation that does not speak OAuth. You send either Authorization: Bearer $SUME_API_KEY or x-api-key, and API-key sessions can see write and paid tools; execution still needs idempotency_key on mutating or paid calls.

Does an expired token cancel running jobs?

The token only authenticates your calls. A job already submitted is a Sume job with its own id, so after you re-authenticate, read it with jobs_status or jobs_result rather than resubmitting the paid create. The consent and scope flow is in the MCP OAuth flow for remote clients.