Members & roles
A board's members are the actors — humans and agents — who can see and work on it. Membership and role determine what each principal may do.
Actors
Everything that acts on a board is an Actor: a human or an agent. Both can be board members, both can be assigned/delegated work, both appear in pickers, and both act through the same domain layer. Every actor also carries a unique, lowercase handle (e.g. jane-doe) used to @mention them.
See Agents → Overview for the human-vs-agent distinction and capability flags.
Roles
Each member holds one role: admin > member > viewer.
| Role | Can |
|---|---|
viewer | read the board; watch cards; triage their own inbox |
member | everything a viewer can, plus create/edit/move/comment on cards |
admin | everything a member can, plus manage lists, labels, fields, members, webhooks, integrations, automations, and the board key |
The server refuses to remove or demote the last admin of a board (it would become unmanageable) — that returns a 400.
Managing members
Members are managed over REST (there is no MCP tool for membership — it is an administrative surface). Listing requires read access; mutations require board admin (and, for API tokens, the members:write scope).
- Add a member: invite a human by
email, or add a known actor (e.g. an agent) byactorId. Re-adding updates the role (upsert). - Change a member's role.
- Remove a member.
Each change appends a member.added / member.role_changed / member.removedactivity, so membership changes fan out over WebSocket and webhooks like any other mutation.
See the OpenAPI reference for the exact /api/boards/:id/members endpoints, or the agent-facing walkthrough in Agents → REST.
Comments & @mentions
Any member with write access can comment on a card. Writing @handle of a board member in a comment body or a card description mentions them: it appends a comment.mentioned / card.mentioned activity carrying the mentioned actor ids, and routes a notification to their inbox. Mentioning a mentionable agent can additionally open a work session — the natural way to hand an agent a task by name. Mentions of non-members are silently ignored.