POST /oauth/revoke on Sume MCP: 200 even for a token it never saw

To revoke a Sume MCP OAuth access token, send the token to POST https://mcp.sume.com/oauth/revoke as form fields or JSON. The endpoint answers HTTP 200 with an empty body. It does that whether or not the token was known, so a 200 is not proof that something was revoked. The proof is a later call with the same token that no longer works.

The behavior follows the usual OAuth revocation rule: the endpoint should not tell a caller whether a token existed. In the Sume source, a token that does not carry the MCP access-token prefix is skipped without a lookup, and a token that does carry it is revoked by its hash, then the route still returns 200.

That design means your own code must not branch on the status code. Log the call, treat 200 as "request accepted", and prove the outcome with a follow-up call. A 4xx from the revoke route is reserved for a malformed request, for example a missing token field.

What you can and cannot revoke

Revocation exists for the access token only. The access token is valid for one hour and there is no refresh grant (the authorization-server metadata lists authorization_code as the only grant). So revoking ends the session for good: the client has to run the OAuth login again.

There is one more limit to keep in mind. Revoking an access token does not delete anything the session already created. A paid job that was submitted with that token keeps running and billing, and its result is still readable by the same member on a new session. Cancel such a job separately with jobs_cancel (a write tool, so it needs the Write scope or an API key) and only before generation starts.

• You can revoke an MCP OAuth access token.
• You cannot revoke a Sume API key at this endpoint. API keys are managed in the dashboard.
• There is no refresh token to revoke.
• An OAuth token is not an API key, so rotating one does nothing to the other.

Confirm that the revoke worked

Because the response does not tell you, test with a read-only call. Use a tool that exists for every session, such as mcp_health, and compare the two calls.

Keep a note of where each client stores the token. Desktop clients use the operating system keychain or a credentials file; a revoke that is sent for a token copy that lives only in a shell variable will not log the client out of its own session.

TOKEN="paste-access-token-here"

curl -s -o /dev/null -w "revoke: %{http_code}\n" \
  -X POST https://mcp.sume.com/oauth/revoke \
  -d "token=$TOKEN"

curl -s -o /dev/null -w "mcp after revoke: %{http_code}\n" \
  -X POST https://mcp.sume.com/mcp \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Reading the two outputs

The first line should print 200. The second should print an authentication failure status rather than a tool list. If it still lists tools, the token you revoked is not the one the client uses; some clients keep it in a keychain entry that is different from the file you checked.

For automation that has to check many tokens, run the second call with a read-only tool and treat any HTTP 401 as proof, and any tool list as evidence that the revoke did not apply.

After a leak

The credential safety rules in the docs apply here: an OAuth token is not a Sume API key, do not paste it into prompts, and rotate any key that shows up in logs or chat history. If a client leaked a token, revoke it, sign in again, and read the new scope on the consent page. Write access is a toggle that is off by default, so a new sign-in is also a chance to grant less than before.

For an operator who has to end a session fast, the order is: revoke the token, confirm with the second call, then ask the person to run the client's sign-in command again. If the client auto-reconnects, expect it to open the consent page, where the Permissions section shows Read locked on and Write off by default.