Using Tokening With Claude Code, Cursor and Claude Desktop
Most people meet MCP through a coding assistant or a desktop chat app. Each of them can talk to an HTTP MCP server and send a bearer token, which is all Tokening needs. Here’s the full loop: issue a grant, point the client at Tokening, give the agent its task and read what happened.
This assumes Tokening is already running with a WordPress target called demo-wp. If it isn’t, steps 2 to 5 of the quick start take about ten minutes.
Issue a grant for the task
Decide the task first, then issue exactly that.
tokening grant issue wp.edit-post-text \
--bind id=4812 --uses 1 --ttl 15m \
--to claude-code --by me --reason "tighten the intro of post 4812"
Copy the secret from the reply. You won’t see it again.
Point the client at Tokening
Claude Code takes one command:
claude mcp add --transport http tokening http://127.0.0.1:8080/mcp/demo-wp \
--header "Authorization: Bearer GRANT_SECRET"
Cursor reads ~/.cursor/mcp.json. Keep the secret in an environment variable so it doesn’t end up in a file you might share:
{
"mcpServers": {
"tokening": {
"url": "http://127.0.0.1:8080/mcp/demo-wp",
"headers": { "Authorization": "Bearer ${env:TOKENING_GRANT}" }
}
}
}
Claude Desktop connects to local tools through its config file, so use the mcp-remote bridge to reach an HTTP server with a header:
{
"mcpServers": {
"tokening": {
"command": "npx",
"args": ["-y", "mcp-remote", "http://127.0.0.1:8080/mcp/demo-wp",
"--header", "Authorization:${TOKENING_AUTH}"],
"env": { "TOKENING_AUTH": "Bearer GRANT_SECRET" }
}
}
}
The value sits in env without a space after the colon because some Windows setups break arguments that contain spaces.
Give the agent its task
Ask for the job in plain words: “Tighten the first paragraph of post 4812. Keep the title.” The client lists its tools and finds one, wp_update_post. That’s all the grant allows, so it’s all the agent sees.
If the agent wanders, the refusal comes back as a normal tool error, and the text is written to be read: “Grant is bound to id 4812; call sent id 4813.” Most models take the hint and stop. If you’d like the agent to check its limits before it starts, tell it to fetch GET /grant, which describes the grant without spending it.
Read what happened
tokening grant inspect g_...
You’ll see uses left and every decision, allowed or refused, with its reason. tokening log --follow shows decisions live across all grants. When the task is done, the grant is spent. For the next task, issue a new one and swap the secret in the client config.
A word on testing
Tokening 0.1 is tested end to end with its own scripted MCP agent. These three clients use the standard HTTP transport and bearer header, and full client testing is planned for 0.2. If one of them trips over something, let us know with the client version and the refusal code you saw.