Mcp

Personal vs Workspace MCP/API Keys

Which Excalidraw+ MCP/API key type to use for MCP and integrations

Excalidraw+ has two different key types you may encounter in settings:

  • Personal MCP/API keys
  • Workspace API/MCP keys

They are both valid for API and MCP access, but they are meant for different jobs.

Quick recommendation

Use a personal MCP/API key when an AI agent or script should act like you. Use a workspace API/MCP key when you are building a system integration that should act on behalf of the workspace instead of a single person.

At a glance

Key typeBest forActs likePrivate collection access
Personal MCP/API keyAgents, assistants, personal scriptsA specific memberYes
Workspace API/MCP keyn8n, Zapier, backend jobs, shared integrationsThe workspace/integrationNo

Personal MCP/API keys

Use a personal key when the automation should behave like a real member inside Excalidraw+.

Workspace admin required

Personal MCP/API keys are not always available by default. A workspace admin must enable personal MCP/API keys in workspace settings before members can create or use them.

Typical examples:

  • Connecting AI coding agents or assistants
  • Personal MCP setups in tools like Cursor, Claude Code, OpenCode, or Codex
  • Small scripts that should use your own access and context

Why choose a personal key:

  • It is tied to a specific member
  • It can access that member's private collection
  • It is usually the best choice when the agent is helping one person directly

If your goal is "make this agent work like me inside Excalidraw+", start with a personal key.

Workspace API/MCP keys

Use a workspace key when the integration should represent the workspace rather than one specific member.

Typical examples:

  • n8n workflows
  • Zapier automations
  • Internal backend services
  • Shared integration servers or bots

Why choose a workspace key:

  • It is better suited for long-lived system integrations
  • It keeps the integration separate from one person's account
  • It does not access any member's private collection

If your goal is "connect this workspace to another system", start with a workspace key.

Main difference: private collection access

The biggest behavioral difference is private data access:

  • Personal MCP/API keys can access the key owner's private collection
  • Workspace API/MCP keys cannot access members' private collections

This is why personal keys are usually better for assistants and agents, while workspace keys are safer and clearer for shared automations.

Using the private collection

With a personal key, use private as the collection ID to address the key owner's virtual private collection. This works consistently across REST and MCP:

  • list_collections includes a collection named Private with ID private
  • list_scenes and list_collection_scenes accept collectionId: "private"
  • create_scene and create_collection_scene accept collectionId: "private"
  • update_scene accepts collectionId: "private" when moving one of your own scenes into your private collection

API responses normalize private scenes to collection: "private". Internally, private scenes are identified by having no persisted collection (collection: null); clients should use the normalized private collection ID rather than depending on the isPrivate compatibility field.

Each member has exactly one virtual private collection. It cannot be created, renamed, or deleted. create_collection and POST /collections always create a regular shared collection; they cannot create another private collection. Workspace keys do not list the virtual private collection and cannot use private to read, create, or move scenes.

Which one should I choose?

Choose a personal key if:

  • The tool is helping one person
  • The agent should see that person's private work
  • You want the integration to behave like a member session

Choose a workspace key if:

  • The integration is shared by a team
  • The workflow should not depend on one person's account
  • You are building operational automations or external system syncs

Last updated on

On this page