This is the MCP / AI reference for systemHUB — written for AI agents and developers. If you are a person looking for how-to help, use help.systemhub.com instead.

Guide: audit access, sign-off & training

The read side of governance: who can see a document, who has agreed to it, who has completed the training on it, who has touched it, and what a given person owns. Bodies below are abridged and illustrative — see the tool reference for the full contracts.

Who can access this document, and how?

→ get_document_members_and_roles { "documentId": "7d4f2a90-…", "topicType": "system" }

{
  "roles": [{ "title": "Client Delivery" }],
  "members": [
    { "name": "Jane Smith",  "email": "jane@acme.com",  "accessType": "role-based", "roles": ["Client Delivery"] },
    { "name": "Sam Nguyen",  "email": "sam@acme.com",   "accessType": "direct" },
    { "name": "Priya Patel", "email": "priya@acme.com", "accessType": "both", "roles": ["Client Delivery"] }
  ]
}

Present it as an audit: roles first, then members grouped by how they got in (direct vs role-based vs both). Access is the union of the two mechanisms — see Roles & seats.

Who has signed off?

→ get_document_agreement_status { "documentId": "7d4f2a90-…", "topicType": "policy" }

Returns each assigned member with agreed / not-agreed status — the compliance view for policy acknowledgements (“who has actually agreed to the new leave policy?”).

Who has completed the training?

→ get_document_training_progress { "documentId": "b2c91e08-…" }

Returns per-user completion percentage and status for a training document. Combine with get_document_members_and_roles to report “assigned vs actually completed”.

What does this person own?

→ list_documents_by_owner { "owner": "Jane Smith", "fetchAll": true }

[
  { "id": "…", "title": "Onboard a new client", "section": "system",  "state": 3, "materializedPath": "3. Client Delivery" },
  { "id": "…", "title": "Leave policy",         "section": "policy",  "state": 1, "materializedPath": "HR" }
]

One call spans systems + policies + trainings (omit section for all three). The name must match exactly or the call returns a 400 — when unsure, use the person’s user UUID (visible on tree nodes as ownerId). ownership defaults to either (primary OR secondary owner).

Who created or changed this document?

→ get_document_activity_log { "documentId": "7d4f2a90-…", "topicType": "system" }

Returns creation (who/when), last modification (who/when), and the event feed — pass includeViews: true to include view events. Lead with creation and last-modified when presenting; the feed is supporting detail.

Was this an AI or a person?

Every event carries agentCall (live on production since 19 Oct 2026): true when the change came through an MCP call, false when it came from the web app, where the same thing shows as via MCP next to the action. It works across systems, policies and trainings, which makes “what has the agent been doing in here?” an answerable question for the first time.

⚠️ Two limits to state out loud before you report on it. Events recorded before the release are unlabelled, so the absence of agentCall: true on an older event proves nothing — don’t read a quiet back-catalogue as evidence that no agent touched it. And writes made with a company API key are not flagged yet: they still look like app edits. So agentCall: false means “not through MCP”, not “a human did this”. If you are presenting this as an audit, say which window is labelled.

Know what this still can’t answer. It tells you that a document changed, who changed it and whether an AI did it. It does not tell you what changed — events carry an action and an entity, not a field-level diff. So it supports “who last touched this, and was it the agent?” and not “which paragraph did the agent rewrite last Tuesday?”. If you need the latter, cut a named version before the change (see Document lifecycle); there’s no way to reconstruct it afterwards.

Fixing what the audit finds

Access audits usually end in an assignment change, and that’s now writable:

→ list_company_members { "search": "Priya Patel" }        // resolve name → userId
→ manage_document_members { "documentId": "7d4f2a90-…", "topicType": "system", "action": "add", "userIds": ["…"] }

Resolve names with list_company_members / list_roles first (never ask the user for UUIDs), then verify the result with get_document_members_and_roles. Seat provisioning (inviting new people, licences) remains app-UI only.

Recipes these unlock

• Offboarding sweep: list_documents_by_owner for the leaver → report everything that needs a new owner.
• Review-debt report: walk the tree and group by owner using reviewDate (on every response) — anything in the past, plus anything with reviewDate: null. Don’t filter on state: 2 (RED) alone; RED is set manually, so an untended library reports zero debt. Budget for the cost: reviewDate isn’t queryable or sortable in bulk, so this means walking the tree and reading it per document — on a large library, scope to one department at a time rather than attempting the whole account in one pass.
• Compliance gap: agreement status across every policy → who hasn’t signed off, per policy.
• Training rollout check: progress on each training in a learning track → completion by team.

The boundary

Document-level assignment is writable (manage_document_members); seat provisioning is not — inviting new people to the workspace, allocating licences, or changing company-role membership happens in the app UI. Don’t attempt those; direct the user there instead.