We host one SDODS server for the QA group. Everyone wants to point their editor at /mcp so they can ask about runs and coverage without a checkout.
What I do not want is somebody's editor deciding to start a regression run against staging at four in the afternoon. Can I hand out a token that can read and nothing else?
Accepted answer
Yes, and it is the intended shape of a shared server. Over HTTP the bearer token's scopes decide which tools even appear in the client's list — a tool the token cannot call is not advertised, so the model never tries and never has to be told no.
sdods tokens create --user koen --name editor --scopes projects:read,features:read,runs:read,artifacts:read --expires 90dRoughly:
project_*, feature_*, step_*, run_* reads, analyze_*,heal_*, data_*, schedule_*.
runs:write: run_tests and run_tests_async appear. This is the one you are worriedabout.
features:write: feature_write appears, and it still only writes a proposal.Tokens are free, unlimited and revocable, so issue one per person rather than one for the team. That way revoking is not an event.
The Settings page does the whole thing without the CLI, and it also hands you the client snippets already filled in with your endpoint, which saved me from typing the header wrong twice.
The Test connection box is the useful bit — paste the token, press Test, and the tool chips above update to what that token actually resolves to. Faster than restarting an editor to find out.
One rule that catches people: a token's scopes must be a subset of its owner's role, both when it is created and every time it is used. So a token created by an admin for a viewer account does not grant admin, and demoting somebody quietly narrows every token they own.
If a colleague's tools disappear one morning, check their role before you check the token.
Separate token for CI, separate scopes: runs:ingest,runs:read and nothing else. Do not reuse a person's editor token in a workflow — when they leave, the pipeline goes with them.
Have a different question? Ask it.