Roles, members & seats

systemHUB controls who can see and do what through roles and member assignments. This page explains the model an agent needs to reason about access — and where the current MCP boundary sits.

The access model

A document’s access is the union of two mechanisms:

A member can therefore have access that is direct, role-based, or both. The get_document_members_and_roles tool returns exactly this: the roles on a document, plus each member’s name, email, role title(s), and access type.

Present an access picture as an audit: roles first, then members grouped by how they got in (direct vs role-based vs both).

Seats

A seat is a licensed member of the workspace. Seat/member management — inviting people, allocating seats, changing who holds which role — is done in the systemHUB app UI.

MCP boundary (important for connecting agents): the MCP server can read the full access picture (members, roles, assignment type, agreement status, training progress) but does not currently expose write-side user or seat management. An agent can audit and report on access; it cannot add members, change seats, or reassign roles through the MCP. Attempting to do so is out of scope — direct the user to the app UI.

What agents can audit today

Together these cover “who owns / can see / has completed what” — the read side of governance. The write side (provisioning) stays in the app for now.

Next: Authoring content →