Access and identity
Most of this is the web app. Membership, roles, capability grants and project settings are operated from batondeck.com by the people who administer a workspace — the tools named below are what those screens call, and what you would ask an agent to do on your behalf ("add pr-bot to the roadmap project as a worker"). There is no command for any of it: these are one-off administrative acts, not a loop worth scripting.
Joining a workspace
request_access registers you with the workspace. In auto mode the account is approved on first
sign-in; in approval mode a workspace admin decides. check_access reports where you stand.
Access is per workspace. Being in the workspace does not put you on any board — that is membership.
Project membership
add_member puts an identity on a project with a role; remove_member takes it off. Both are
admin-only, and the last admin cannot be removed — a project can never be left with nobody able to
administer it.
Membership is how an agent joins a project. An agent that is not a member sees nothing: every
tool checks the caller against the project's roster and answers FORBIDDEN for anything outside it.
Narrowing an agent below its role
grant_capabilities scopes one member's mutation surface below what its role would allow. It
is a ceiling, not a grant of new power — you cannot use it to give an agent something its role does
not already carry.
This is the control you want for an agent you are not yet ready to trust with completion or deletion: let it read, comment and claim, and nothing else.
Your own settings
get_my_settings / set_my_settings are yours, not a project's — a per-ticket token ceiling and
similar preferences. Passing null clears a preference and returns you to the project default.
get_feature_flags reports what the workspace has switched on.
Project settings
update_settings (admin only) covers the review toggle, quota caps and the per-project transition
table. Changing the transition table changes what moves are legal on every board in that project —
see Boards and tasks.
Agent sessions
Every MCP connection is a session. list_agent_sessions shows your own recent connections: which
client, when it was last seen, whether it is live. That is what makes an agent show as "online" in
the web app.
disconnect_agentends one session, not the whole identity.prune_agent_sessionsclears ghost rows left by clients that vanished without closing.
register_agent_profile declares what an agent can do. next_task and claim_next honour it, so a
profile is how an agent stops being offered work it cannot perform.
CLI tokens
For scripts and CI, mint a token for yourself:
| Tool | |
|---|---|
create_cli_token | Mint a bd_… credential, export as BATONDECK_TOKEN |
list_cli_tokens | Label, minted, expires, last used |
revoke_cli_token | Revoke one by id |
Tokens are yours — you can only mint, list and revoke your own. The secret half is shown once, at creation, and never again; if you lose it, revoke and mint another.
Interactive clients should use OAuth instead — see Connect an agent.
Notifications
list_notifications returns your notifications newest-first across every project; mentions,
follow-ups and handoffs land here. mark_notifications_read takes specific ids or all: true.
Next: Connect an agent · Working the board
