# Team / Member Management Each Gakaso project has its own membership list, separate from the account-level sign-in identity discussed in `/auth.md`. ## Roles and what they actually grant | Role | Effective permission | Notes | |---|---|---| | **Owner** | `read`, `write`, `admin` | Full control, including membership changes. The project creator by default. Only one owner per project; a project always has exactly one. | | **Editor** | `read`, `write` | Can edit the canvas, tokens, and other project content. | | **Agent** | `read`, `write` | **Functionally identical to Editor** — the permission model does not currently give "agent" any different capability than "editor"; it's a distinct label mainly so a project's member list (and canvas presence cursors, per `/canvas/application-mode.md`) can visually distinguish "this access belongs to a bot/API key" from "this access belongs to a human editor." Don't assume an agent-role key can do anything an editor-role key can't, or vice versa. | | **Viewer** | `read` only | Read-only access. | The important asymmetry to know before attempting a membership change: **adding, updating, or removing a member requires `admin` permission — which only the Owner role has.** A key belonging to an Editor- or Agent-role member can freely read/write canvas content, tokens, pages, etc., but calling `gakaso_manage_project_members` with `action: "add"/"update"/"remove"` from such a key fails with `FORBIDDEN` (`-32003`). `action: "list"` only needs `read`, so any member (including Viewer) can list. ## Managing membership via MCP `gakaso_manage_project_members` is a single tool with an `action` parameter: | Action | Effect | Required permission | Notes | |---|---|---|---| | `list` | List current members (`userId`, `email`, `name`, `role`, `createdAt`) | `read` | | | `add` | Add a user to the project with a given role | `admin` | `userId` and `role` (`editor` / `viewer` / `agent`) both required. Fails with `CONFLICT` (`-32002`) if already a member; fails with `NOT_FOUND` if the target user doesn't exist as a Gakaso user yet (they must already have some account — this tool doesn't invite-by-email or create accounts). | | `update` | Change an existing member's role | `admin` | `userId` and `role` required. Cannot be used to change an existing **Owner**'s role. | | `remove` | Remove a member from the project | `admin` | `userId` required. **Cannot remove yourself** (even as Owner), and **cannot remove the Owner**. | You (or anyone) cannot assign the **Owner** role to anyone via this tool in any action — ownership transfer is a project-settings action outside the MCP membership surface, not something to attempt mid-session. This tool is scoped to a single project — it manages who has access to *that* project, not organization-wide user administration. ## Multi-project grouping Separately from per-project membership, Gakaso supports grouping multiple projects together (useful for teams or organizations running several Gakaso projects that should share tokens or be viewed together) via `gakaso_create_project_group` and `gakaso_assign_project_to_group`. This is an organizational convenience layer above individual project membership, most relevant if a human is coordinating several related Gakaso projects rather than a single one. ## What this means for you If a human asks you to "invite my teammate" or "make X an editor," use `gakaso_manage_project_members` with `action: "add"` or `"update"` — but only if the key you're using belongs to the project's Owner. If your key belongs to an Editor/Agent-role member and the call fails with `FORBIDDEN`, that's expected — tell the human they (or the Owner) need to do it, rather than retrying or trying a workaround. If they ask you to transfer ownership or do anything involving the Owner role, that's outside what the MCP membership tool will do in any case — say so and point them at the project's own settings screen.