Skip to main content
Use MCP access when your team wants external AI clients to work from real Custory context instead of re-explaining the workspace in every session.

​
What MCP lets you do

Use MCP when your team already works from Cursor, Claude, or another MCP-compatible environment and wants Custory to become part of that setup instead of staying isolated inside the app.

​
Why workspace-scoped MCP access matters

This gives external AI tools a workspace-scoped way to read and update Custory context without using a broad account-level credential.

​
How key setup works

Custory MCP access uses workspace-scoped API keys. That means:
  • access is tied to one workspace
  • the credential is not a broad global token
  • revoking the key shuts off that client immediately
From Manage Integrations, open the MCP setup and create a key. During creation, set:
  • a key name
  • an expiry policy
The expiry choices are 30 days, 90 days, and Never. Good key names describe the client and machine clearly:
  • Cursor on MacBook
  • Claude Code on CI VM
  • Agent for support triage

​
The copy-once token rule

When a key is created, Custory shows the full token only once. After that, Custory stores a prefix for identification, but not the full secret for later viewing in the UI. If you lose it, create a new key.

​
Example config

Use the MCP endpoint URL and your bearer token in the client you choose. Example Cursor-style config: 
{
  "mcpServers": {
    "custory": {
      "url": "https://app.usecustory.com/api/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_CUSTORY_MCP_TOKEN"
      }
    }
  }
}
Replace the URL and token with the exact values shown in your Custory MCP setup panel.

​
Test the connection first

Custory includes a copyable curl command so you can verify the connection before relying on it in a real agent workflow. This is the fastest way to confirm:
  • the URL is correct
  • the token works
  • the external client should be able to connect

​
Review active keys

Use the Keys tab in MCP setup to review existing keys. Custory shows:
  • key name
  • stored token prefix
  • created time
  • last used time
  • expiry time when one exists
  • current status
  • revoke action for active keys
If a key is old, unclear, unused, or tied to a machine you no longer control, revoke it and create a fresh key.

​
A practical setup pattern

For most lean teams:
  1. create one named key per client or machine
  2. use an expiry period unless you have a strong reason not to
  3. copy the token once into the target client
  4. run the quick test
  5. revoke old or unclear keys instead of reusing them indefinitely

​
MCP setup mistakes to avoid

Per-client keys are easier to audit and safer to revoke. Give each machine or client its own credential so cleanup is simple later.
If the token is not stored when created, the practical recovery path is to create a new key. Treat creation as the one moment where secure storage has to happen correctly.
Revoke keys you no longer trust or use. Small credential cleanup habits matter more than perfect policy language in day-to-day operations.

​
Next step

Read Security and privacy before creating broad external access. Read Overview for the broader tool-connection model.