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.

systemHUB Docs

Machine-readable documentation for connecting AI agents and technical users to systemHUB.

systemHUB is a platform for documenting, organising, and training teams on business systems — Systems (procedures/SOPs), Policies (compliance documents), and Trainings (learning modules). This documentation set describes how an AI agent (via the systemHUB MCP server) or a developer can connect to systemHUB, read a company’s content, and author or maintain it programmatically.

This is the AI-facing surface. If you’re a human looking for friendly, task-oriented help, use help.systemhub.com instead. The two layer together — they don’t replace each other.

Who this is for

• A prospect’s or customer’s AI assistant connecting to systemHUB via MCP, so it can find and use the company’s systems with no friction.
• Technical users / developers integrating with, or building on top of, the systemHUB MCP server.

Start here

1. Getting started — connect the systemHUB MCP server and make your first call.
2. Quick wins — verified copy-paste prompts for a newly connected agent.
3. Teach your AI — make it stick: the first-session prompt and the briefing your AI saves into its standing context.
4. Document lifecycle — how documents, states, and publishing work.
5. Roles & seats — how access is granted and counted.
6. Sharing & links — app links (login required) vs public share links (no login, machine-readable).
7. Authoring content — the formatting contract: what survives the editor and what gets stripped.
8. Errors & limits — known failure modes and validation limits, stated up front.
9. Tool reference — every MCP tool, its inputs, and what it returns, generated from the schema snapshot (the page states how old that snapshot is).

Guides (worked examples)

Task-oriented walkthroughs with request→response examples:

• Build a Business Brain — the six-section folder in Policies that tells any AI who the business is and how it runs: set it up once, then keep adding.
• Make systemHUB your AI’s source of truth — point every AI at one place, then make a process change land everywhere the same fact is repeated: the update, the sweep, and the claims register that stops it going stale in six places at once.
• Draft an SOP into systemHUB — orient, dedupe, create to the house format, attach templates/media, version.
• Audit access, sign-off & training — who can see what, who’s agreed, who’s completed training, what a person owns.
• Organise & maintain the library — folders, moves, states, tags, learning tracks, master templates.
• Publish your AI’s skills — give the skills your team has built a visible home: index by outcome, attach the file, and split shareable from business-wired.
• Index your automations — make the jobs that run without anyone pressing a button visible: the real schedule, the runner, the owner, and what to do when one stops.

What you can do through the MCP today

• Discover & read — browse the folder tree; search systems, policies, and trainings by name; read full document content, owners, tags, media, and attachments.
• Audit — see who a document is assigned to (members & roles), agreement/sign-off status, and training completion progress.
• Author & maintain — create, edit, move, and publish systems, policies, trainings, folders, learning tracks, tags, and media.

Known limits

These are documented honestly so a connecting agent doesn’t try what isn’t there yet:

• No seat provisioning via the MCP — inviting people and allocating licences happens in the app UI. (Document-level member/role assignment IS available — see manage_document_members.)
• MCP access is on for admins by default. For Editor, Contributor and Reader seats, systemHUB support switches it on (customer admins can’t do it themselves; email support@systemology.com). Each connection runs as the person who approved it, with exactly that person’s permissions, so a Reader’s AI can read but not change anything. See Roles & seats. There’s still no admin view of which agents are connected, and no way to revoke one connection without affecting your others.
• Tokens expire after 180 days, with a reminder at day 144. Worth diarising if you’ve built anything that runs unattended — it will stop working on that date.
• Unattended automation uses a company API key, which is a separate path from the MCP. The MCP connection is per-user OAuth, built for a person’s AI client, and its token expires after 180 days — so it is the wrong tool for a cron job. For that, systemHUB has company API keys: created in the app, sent as an x-systemhub-api-key header to api.systemhub.com, tied to a specific user so the key inherits that person’s permissions and document ownership, revocable immediately, and every successful call is recorded in API Key Logs with the method, endpoint, key name, user and time. Verified in production by the systemHUB team on 28 Sep 2026. Two things to know: it authenticates REST calls, so the MCP tool surface documented here is not what you get through a key — and refused calls (401/403) are not logged, only successes. Who can create and see keys is being brought into line with AI Gateway access, so check in the app rather than assuming.
• No workspace-wide usage analytics via the MCP. (Per-document activity, including views, IS readable — see get_document_activity_log, whose events have carried an agentCall AI-or-person flag since 19 Oct 2026.)
• Company API-key writes aren’t flagged as agent activity yet. The activity log marks MCP calls (agentCall: true) and app edits, but a write made with a company API key still looks like an app edit. So agentCall: false means “not through MCP”, not “a person did this”. Tracked with the product team.
• No deletes, deliberately — an agent can create, edit, move and publish, but never delete. That’s a decision, not a missing feature: removing a document stays a human action in the app.
• An agent can still replace a document’s contents — but version history is now reachable. list_document_versions lists the published snapshots (newest first, versionId + title + createdAt, no bodies) and restore_document_version rolls one back onto the live document by versionId. Restore by id, never by date or title. A restore brings back more than the body. Tested on production 25 Oct 2026 on a throwaway document: body, Overview, note and tags all came back, including removing a tag that had been added after the snapshot. reviewDate did not come back and kept its current value, which matches the tool’s own list (it never claims to restore a review date). Videos, templates and attachments were not part of that test. So publish_* before a substantial rewrite is a real safety net for content and metadata, though not for the review date. Treat writes to approved documents as consequential anyway: a restore is a rollback, not an undo, and there is still no way to see what changed.
• Images cannot be injected via the API — they’re uploaded through the editor. See Authoring content.

Recent capability changes are tracked in the changelog.

For AI agents reading this

Every page on this site is also servable as plain markdown — append .md to the page URL (e.g. /docs/getting-started.md). A machine-readable index lives at /llms.txt.