Cursor sends refresh_token at MCP registration: Sume ignores it

Sume's hosted MCP server accepts a dynamic client registration that lists refresh_token in grant_types, and it ignores that entry. The registered client always comes back with grant_types: ["authorization_code"]. A source comment says why: clients such as Cursor often advertise refresh_token, and refresh is not implemented yet, so the server only stores the authorization-code grant. The practical result is a one-hour access token and a new sign-in after that.

If you see a connector drop after about an hour with an authentication error, this is the expected behavior and not a broken registration.

Because the omission is silent, the registration response is the place to look. Compare the grant_types you sent with the ones that came back; a difference is the sign that the server changed your request on purpose.

What the registration response says

Registration is POST /oauth/register on the MCP host. A client posts its metadata and gets back a client_id. The public-client rules are fixed: the auth method must be none, so no secret is ever issued.

What is rejected and what is tolerated

A request that lists any grant type other than authorization_code and the optional refresh_token is rejected with an error saying the grant types may only include those two. So the dropped value is the one case that is tolerated on purpose, to keep real clients from failing at registration.

The tolerance is narrow on purpose. It keeps clients that always advertise a refresh grant from failing at the very first step, while the response stays honest about what is supported. A client that reads the registration response and sees only authorization_code should not try the refresh grant at the token endpoint, because the authorization-server metadata also lists only the code grant.

What it means for long sessions

The consequence for an unattended agent is simple. A session that you connected through OAuth is good for one hour from the token exchange. Long jobs are not affected, since a job keeps running after the session ends: store the job id and read it back with a new session. An overnight automation should use an API key instead, which the docs describe as the other path for automation that does not use OAuth.

Think of the hour as the unit of an interactive session. Anything that needs to survive it, such as a long render, must hand over its state to something durable: the job id. Sume jobs belong to the workspace and the member who created them, so a new session for the same member can read the job again after the sign-in. The jobs page in the docs lists the status, result and events reads for this.

Practical rules

Plan around the hour like this:

Teams often ask whether a longer session can be bought or configured. The one-hour value is a constant in the OAuth package, not a per-workspace setting, so the options are the ones above: sign in again, or use an API key for unattended work.

• Keep interactive agents on OAuth with Write off unless you need it.
• Put scheduled or unattended runs on an API key sent as Authorization: Bearer or x-api-key.
• Save job ids from paid calls so a fresh session can read them with jobs_status or jobs_result.
• Treat an authentication error after an hour as a signal to sign in again, not as a Sume outage.

Connect steps for each client are on the MCP quickstart, and the full auth matrix is in MCP OAuth and API keys.