What is an MCP token, and how do I scope it?
An MCP token is the credential an MCP client presents to a server. Scoping it limits which tools and which records it can touch. Issue one per agent per purpose, with an expiry, and revoke it on any anomaly.
The short answer
- An MCP token is the credential an MCP client, Claude, Cursor, a custom agent, presents when it connects to an MCP server. The server uses it to decide which tools that client can call and which records it can touch.
- Scoping a token means limiting it along the same axes any permission system should use. Which objects it can access. Which channels or accounts it acts through. Which actions (read, write, send, delete) it may take.
- Issue one token per agent per purpose. Do not share one token across several agents or use cases. That is what makes an audit log attributable to a specific agent, rather than a shared credential nobody can pin down.
- Set an expiry on every token, even for a long-running trusted agent. Revoke at once on any anomaly: unexpected call volume, calls outside the expected scope, activity at unusual times. Do not wait to confirm something is wrong first.
What the token is actually doing
When an MCP client connects to a server, the server has to decide two things. Is this client who it claims to be? What is it allowed to do? The token answers both. It authenticates the connection, proving the client holds a credential the server recognizes. In a well-built server, it also carries or maps to a specific scope: the set of tools and records that token may touch, distinct from what any other token may touch.
That second part, the scope, is what separates a well-designed MCP token system from one that only checks "is this a valid token". A server that authenticates every token but then grants full access to any valid one has built authentication without authorization. The difference matters. A leaked token in the first kind of system can do everything the server allows. A leaked token in the second can only do what its scope permits.
Scoping axes for an MCP token
| Scope axis | Example | Default |
|---|---|---|
| Objects | Deals and contacts in one pipeline, not billing or user records | Narrow to what the token's purpose requires |
| Channels or accounts | One connected mailbox or one LinkedIn queue, named explicitly | Never 'all connected channels' by default |
| Actions | Read always on; write per action class; send and delete off unless explicitly needed | Read-only until a specific need justifies more |
Managing tokens as an ongoing practice, not a one-time setup
Issuing a well-scoped token is the easy part. Keeping the token inventory clean over time is where teams tend to slip. A token issued for a two-week pilot, still active eight months later with the same broad scope, is a common and avoidable gap. Review active tokens on a schedule. Check whether each one's scope still matches its purpose. Revoke anything no longer in use. That closes the gap before it becomes a real incident.
Disclosure: SalesCrew is our product. Its MCP tokens are scoped by the same three axes as a human user's access: channel, profile and area. They can be issued and revoked from Settings or through the `mcp_token_issue` and `mcp_token_revoke` tools themselves. Every call made under a token is written to the audit log with that token as the actor. That is what makes an anomaly traceable back to a specific credential.
A token in a shared config file is a token in version control
Questions
- Is an MCP token the same thing as an API key?
- They are similar in concept. Both are credentials presented to authenticate a request. An MCP token specifically authenticates a client to an MCP server. It usually carries the scope the server uses to decide which tools and records that client can access.
- What counts as an 'anomaly' worth revoking a token over?
- Unexpected volume from a token that normally makes a handful of calls a day. Calls to tools outside its expected scope. Calls at times that do not match the agent's normal schedule. Any of these is worth investigating. Revoking the token while you do costs little if the activity turns out to be fine.
- Should a token ever have no expiry?
- Generally no. Even a token for a long-running, trusted agent benefits from periodic renewal. It forces a regular moment to ask whether the scope still matches the job, rather than a token issued once and never revisited.