> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Issue MCP automation keys for team members

> Mint a member-bound Thread MCP access key for automations that can't sign in through a browser, who can issue keys, the required expiry, how the key is shown once, and how to revoke it.

<Note>
  MCP automation keys are a limited-availability feature in partner beta. Thread
  enables them per workspace. Contact your Thread representative or CSM if you'd
  like them turned on for your workspace. Until then, requests that issue a key
  for another member return a 403 error.
</Note>

Thread MCP normally authenticates with OAuth 2.1: the person connects their AI client, signs in with their Thread account, and the client acts as them. That works for a technician at a laptop, but not for automation platforms like n8n, CI pipelines, or scripts that can't complete a browser sign-in.

MCP automation keys close that gap. A workspace admin or team admin issues a long-lived access key bound to a chosen member. The automation presents the key as a bearer token, and Thread MCP treats every call as that member: same tools, same permissions, nothing more. Every key records who issued it, so you always know which admin created which credential.

Prerequisites:

* Thread MCP is enabled for your workspace. See the [Thread MCP server developer guide](/super-magic/thread-mcp-server-developer-guide).
* MCP automation keys are enabled for your workspace (see the note above).
* You are a workspace admin or team admin. Non-admins can only create keys for themselves.
* The member the key will act as has an active seat in your workspace.

## Decide which member the key should act as

The key inherits the bound member's exact Thread permissions. Pick the member whose access matches what the automation needs, and nothing more:

* A read-only reporting job should bind to a member without write access.
* An automation that creates tickets needs a member who can create tickets in Inbox.

Team admins have two extra limits. They can only issue keys for members on one of their own teams, and they can never issue a key bound to a workspace admin. Workspace admins can issue keys for any active member.

## Issue the key in Thread Admin

When MCP automation keys are enabled for your workspace, workspace admins and team admins see an **MCP keys** page under **Magic AI** in the Thread Admin navigation:

1. Open **Admin → Magic AI → MCP keys**.
2. Select **Generate token**.
3. Pick the member the key acts as, give the key a name (for example `n8n production`), and set an expiry. The expiry defaults to 90 days and can be at most one year out.
4. Select **Create**. Thread shows the key in plaintext exactly once, along with copy-ready setup snippets for Claude Code, Claude Desktop, Cursor, and a cURL verification call. Copy the key immediately and store it in your secrets manager; Thread keeps only a hash.

The same page shows the Thread MCP connector URL for interactive OAuth clients, and a table of the keys you can manage with each key's bound member, who issued it, when it was last used, its status, and a **Revoke** action. Workspace admins see every key in the workspace. Team admins see keys bound to members on their teams, plus their own keys.

## Issue the key with the API

You can also send a `POST` request to `/api/v1/mcp/tokens` on the Thread API, authenticated as your own admin account:

```json theme={null}
{
  "name": "n8n ticket sync",
  "expires_at": "2027-03-01T00:00:00Z",
  "member_id": 4821
}
```

* `name`, a label for the key (1–100 characters). Name it after the automation that will use it, not the person.
* `expires_at` — when the key stops working. Required when issuing for another member, and it must be within one year. Requests without an expiry, or with one more than a year out, are rejected.
* `member_id`, the Thread member the key acts as. The member must belong to your workspace and be active; ids from outside your workspace fail validation. Omit `member_id` to create a key for yourself.

The response returns the key in plaintext exactly once, alongside its metadata (name, bound member, issuer, expiry). Copy it immediately and store it in your secrets manager. Thread keeps only a hash; if you lose the plaintext, revoke the key and issue a new one.

## Use the key in your automation

MCP automation keys start with `mcp_` and work as a standard bearer token against the Thread MCP endpoint:

```bash theme={null}
curl -s -X POST https://api.getthread.com/mcp \
  -H "Authorization: Bearer mcp_YOUR_KEY_HERE" \
  -H "Accept: application/json, text/event-stream" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'
```

Replace `mcp_YOUR_KEY_HERE` with the plaintext key you copied when it was issued. The `tools/list` call is a safe way to confirm the key works: it returns the Thread tools the bound member can use without changing anything.

In an automation platform, paste the key wherever the MCP or HTTP connection asks for a bearer token, with `https://api.getthread.com/mcp` as the server URL. Rate limits are shared with OAuth connections in the same workspace; see [rate limits in the developer guide](/super-magic/thread-mcp-server-developer-guide#rate-limits).

## Review and revoke keys

* Every key stores who issued it and when it was last used, so you can audit which admin created which credential and spot stale keys.
* The **MCP keys** page in Thread Admin lists the keys you can manage. Select **Revoke** next to a key and confirm to disable it.
* With the API, add `?scope=company` to a `GET /api/v1/mcp/tokens` request to list keys beyond your own. Workspace admins see every key in the workspace. Team admins see keys bound to members on their teams, plus their own. Non-admins who request `?scope=company` get a 403 error. Without the parameter, you see only your own keys.
* Revoke a key with `DELETE /api/v1/mcp/tokens/{id}`. Workspace admins can revoke any key in the workspace. Team admins can revoke keys bound to members on their teams, plus their own. Everyone else can revoke only their own keys. A key outside your scope returns a not-found error, so revoking it never confirms that it exists. Revocation is immediate, and revoking an already-revoked key returns an error rather than silently succeeding.
* Keys stop working the moment they expire or are revoked. If Thread disables MCP automation keys for a workspace, keys issued for another member stop authenticating immediately; self-issued keys keep working.

## When to use OAuth instead

Automation keys exist for clients that can't complete a browser sign-in. If a person is connecting their own AI client, such as Claude Desktop, ChatGPT, or Cursor, use the OAuth flow in the [Thread MCP server developer guide](/super-magic/thread-mcp-server-developer-guide) instead. OAuth needs no credential handling, and access ends when the member signs out or loses their seat.


## Related topics

- [Thread MCP Server: Developer Guide](/super-magic/thread-mcp-server-developer-guide.md)
- [Trigger Automations with the Magic Agents Automation URL](/ai-agents/magic-agents-automation-url.md)
- [Trigger Rewst Workflows from Thread Magic Intents](/integrations/thread-rewst-integration.md)