MCP access

AuroraDocs can expose a scoped workspace API to external agents through the independently released AuroraDocs MCP server.

What MCP Is For

Use MCP access when you want an external AI agent or automation client to work with AuroraDocs content using explicit tools instead of scraping the app UI.

Current tool coverage includes:

• search, list, recent, and read objects
• create and update objects
• append blocks
• task helpers
• property helpers
• workspace members
• task-list and task-status discovery
• wiki-style knowledge lookup tools when the workspace knowledge layer is available

Requirements

MCP access is AuroraCloud-scoped:

• you must be signed in
• the workspace must be AuroraCloud-backed
• the token must have the required scopes
• normal workspace membership and role checks still apply

Browser-only and Local folders workspaces are outside the MCP scope unless they are first promoted to AuroraCloud.

Install And Configure

Run the public package from your MCP client's stdio configuration:

npx -y @henrikogard/auroradocs-mcp@0.1.1

Version 0.1.1 is the legacy single-workspace release. It accepts an aur_mcp_... workspace token and requires AURORA_WORKSPACE_ID; it does not implement the client-credential, multi-workspace, or project Resume flow below. Use multi-workspace support only after the public repository publishes and documents a post-0.1.1 public release. Until then, the following steps describe the current AuroraCloud/API branch and the required setup for that future public package release, not capabilities of npm 0.1.1.

The post-0.1.1 client-grant setup is:

1. Open Settings → Workspace → MCP Access as the workspace owner.
2. Enable MCP access. New workspace policies are disabled by default and begin with an owner-only read:objects ceiling, 30-day default / 90-day maximum expiry, no no-expiry grants, and no member request or direct-grant access.
3. Register a client with a device-specific label. Registration grants no workspace access.
4. Copy the aur_mcp_client_... credential immediately. It is shown once and cannot be recovered.
5. Select that client and grant this workspace independently. Start with read:objects; add only the scopes the workflow needs. Repeat the grant step in each additional workspace that should be visible.
6. After a compatible post-0.1.1 package is published, configure it as shown in that release's public setup guide, restart the agent, and call list_workspaces. It must return only currently effective grants.

The following shape is a preview. Replace <POST_0_1_1_VERSION> with the compatible version named by the public repository; do not use 0.1.1 here.

{
  "command": "npx",
  "args": ["-y", "@henrikogard/auroradocs-mcp@<POST_0_1_1_VERSION>"],
  "env": {
    "AURORA_API_URL": "https://api.auroradocs.eu",
    "AURORA_API_TOKEN": "REDACTED"
  }
}

For the post-0.1.1 client credential flow, do not set AURORA_WORKSPACE_ID. Each data tool selects one returned workspace_id or unambiguous workspace_alias; the runtime keeps no shared current-workspace state. The legacy aur_mcp_... credential remains one-workspace-only during migration and still requires AURORA_WORKSPACE_ID.

Follow the public repository's setup guide for Claude Desktop, Claude Code, Codex, Hermes, OpenClaw, smoke testing, and troubleshooting. The MCP package owns its version and release cadence independently from AuroraDocs.

Supported Transport

AuroraDocs MCP access runs through a local stdio server. The public server does not expose a hosted HTTP, SSE, or OAuth MCP endpoint.

Keep aur_mcp_client_... or legacy aur_mcp_... credentials in local MCP client configuration. Do not paste them into arbitrary hosted agent services unless that service is explicitly running the local AuroraDocs MCP server under your control.

Encrypted Workspaces

For E2EE workspaces, MCP cannot decrypt content. Tools return locked or unavailable states rather than ciphertext, including when a user has unlocked plaintext in a first-party client. Browser-only and Local folders content remains unavailable because it is never exposed through AuroraCloud.

Managing Access

Workspace owners manage MCP policy, clients, grants, member requests, and legacy-token migration in Settings → Workspace → MCP Access.

• A grant always includes read:objects. Add read:content, read:tasks, or search only when the agent needs those read surfaces. Do not add write:objects, write:content, or write:tasks to a read-only planner.
• If member requests are enabled, a member registers their own client and requests access; the owner must approve it. If direct member grants are enabled, members still act only for their own client and within the effective workspace/member ceilings.
• An active client/workspace pair can have only one grant. To rotate access for the same client, revoke the old grant first, then create and verify the replacement grant. Other workspace grants stay active.
• If uninterrupted overlap is required during rotation, register a separate client, grant and verify it, move the agent configuration, then revoke the original client or grant.
• Revoke the client identity when an installation or device is lost or retired; this disables all workspace grants for that client.
• During legacy migration, approve only tokens already compliant with current policy. Use Narrow and approve to reduce scopes and bound expiry, or replace/revoke the token. Unapproved active legacy tokens are revoked at the displayed enforcement deadline.

AuroraCloud enforces workspace membership, role permissions, exact token scopes, workspace isolation, audit events, and rate limits server-side. The local MCP server cannot bypass those checks. Workspace and member policy changes take effect on the next request even if a grant record itself did not change.

Privacy Notes

External MCP clients are separate software. Only grant tokens to clients you trust, and review what those clients store in their own logs or histories.