Integrations (external tools)

Ceum can connect to external tools — like Claude Desktop, Cursor, or your own agents — so they can read and update your data on your behalf. Each connection uses an MCP token you create. The Integrations page is where you manage those tokens and keep an eye on what they've been doing.

This page is about connecting external tools with a token. Ceum's own in-app assistant, Rocky, needs no token — you enable what it can do from Assistant settings.

Token management

The page lists your existing tokens with:

Name — your label (e.g. "Claude Desktop", "My Cursor setup").
Token prefix — the first few characters, so you can tell tokens apart.
Last used — when the token last made a call.
Created — when you created it.

Actions:

Create token — choose a name, then set its permissions and scope (below); the full token is shown once so you can copy it. It can't be retrieved later, so copy it before you close the dialog.
Edit — rename a token or change its permissions and scope at any time. The token string itself never changes.
Revoke — turns the token off. A revoked token can no longer connect, but its past activity is kept so you can still review it.

By default the list hides revoked tokens. Toggle to show them along with when each was revoked.

Permissions and scope

When you create or edit a token you decide both what it can do and what it can do it to. Granting the least a tool needs keeps a leaked or misbehaving token from touching the rest of your workspace.

Tool permissions

Permissions are an allowlist of individual tools, grouped by area (tasks, projects, clients, documents, and so on). A new token starts with everything granted; uncheck what the tool doesn't need.

All read / All write — the two toggles at the top flip every read-only tool, or every tool that changes data, across all areas at once.
Read / Write (per area) — the same split, but limited to one area.
Individual tools can always be checked one at a time.

A token can only call the tools you grant it; anything else is refused.

Resource scope

Scope limits a token to specific clients and/or projects. By default a token has Full access — it can act on everything, including items with no client or project (e.g. unassigned tasks). Turn full access off to restrict it, and two independent dimensions appear:

Clients — set to All clients (not restricted), or to a strict allowlist of specific clients.
Projects — set to All projects, or to a strict allowlist of specific projects.

Both are strict allowlists: once a dimension is set to "specific", only what you add is reachable. A record must satisfy both dimensions to be in scope — so it must belong to an allowed client and an allowed project (a dimension left on "All" is not checked).

Watch the overlap. Because both dimensions must match, whitelisting a client and a project that don't overlap means no records match at all — the token sees nothing. If you only want to scope by project, leave Clients on "All" (and vice versa). A record that lacks a link on a restricted dimension (a task with no project, when projects are restricted) is also out of scope.

Anything out of scope is invisible and untouchable: lists return only in-scope records, and acting on an out-of-scope record by ID returns an "out of scope" error. A restricted token can create a new project only when its Projects dimension is "All", and a new client only when its Clients dimension is "All".

Scope is enforced everywhere a record links to a client or project: clients, projects, tasks, documents, transactions, time entries, task comments (through their parent task), relationships (both endpoints), and the workspace search and calendar feeds (which only return in-scope items). It also covers linking itself — joining a task to a project, a project to a client, or a time entry to a task requires both the record and the thing it's linked to be in scope. Things with no client/project link — calendar events, subscriptions, and workspace-wide configuration like statuses, task types, and tags — stay available regardless of scope.

Connecting an external tool

The page shows ready-to-paste configuration snippets for common tools, including Claude Desktop and Cursor. Copy the snippet for your tool, drop in your token, and the tool will connect to Ceum.

Reviewing MCP events

You can review every change made through a connected tool — see Sessions and MCP events. It records the action taken, which token did it, the affected record, and when, so you can audit exactly what your tools have changed.

Workflows

Connect Claude Desktop

Create a token from the Integrations page and name it something like "Claude Desktop".
Copy the full token while it's shown — this is your only chance.
Paste the configuration snippet into Claude Desktop's config and drop in your token.
Restart Claude Desktop. The token's Last used updates after its first call.

Audit a suspicious change

Open the MCP events page and narrow to the date range when the change happened. Find the action that made the change, then cross-reference with the record's own history (see Entity changelog) to see the full before and after.

Rotate a token

Create a new token first, switch your tool over to it, and confirm it works. Then revoke the old one. Revoke any token you think may have leaked.

Tips and edge cases

Tokens can't be shown again. If you lose a token, create a new one.
Past activity survives revocation. Revoking a token doesn't erase what it did — its earlier actions still appear under its old name.
MCP events are kept for as long as your account exists.
Task statuses and types can be project-scoped over MCP. The create/update task-status and task-type tools accept allProjects and scopedProjectIds, and list_task_statuses returns them — so a connected tool can both set and read per-project scope. Assigning a task a status or type out of scope for its projects is rejected with a message naming the offending project.

On mobile

Not available on the mobile app — manage from the web app.