Authentication
Access tokens and MCP sign-in: minting, scopes, expiry, revocation, connected apps, and how to send a token.
Both surfaces authenticate with a Studio access token. A token belongs to one account, carries a subset of five scopes, may expire, and can be revoked at any time. The server stores only a hash; the plaintext is shown once when it is minted. The MCP server also takes sign-in: an MCP client that supports it connects with the server's URL and your approval, no token to copy (see Sign in from an MCP client).
#Mint a token
- Open Account > Developer
Sign in at /studio and open the Account view. The Developer card lists your tokens and the plan’s allowance.
- Name it for what will use it
One token per script, notebook or agent. When one leaks, you revoke that one and nothing else stops.
- Pick scopes and an expiry
The default scopes read and write scenarios and read runs.
runs:writeis off by default because it spends money, andruns:publishbecause it lists runs on your public profile with a note in your name. An expiry is optional; short-lived tokens for CI are a good habit. - Copy it
The token is
dsk_followed by 64 hex characters. It is shown once. Store it in a secret manager or an environment variable, never in a repository.
#Send it
Send the token as a Bearer header on every request. Both surfaces also accept an x-api-key header.
GET /api/v1/me HTTP/1.1
Host: daishi.ai
Authorization: Bearer dsk_1a2b3c4d...GET /api/v1/me HTTP/1.1
Host: daishi.ai
x-api-key: dsk_1a2b3c4d...#Sign in from an MCP client
An MCP client that supports sign-in (desktop and web chat apps that take a custom connector by URL, IDE agents, command-line clients) needs only the address https://daishi.ai/mcp/studio. Add it as a remote server or connector; the client opens a Daishi page that shows the name the app gave itself, where it will return you, and the permissions it asks for. Sign in if you are not already, tick what it may do and approve: the app is connected.
| Connected apps | How they work |
|---|---|
| Where it works | The MCP server only. The REST API refuses its tokens; scripts use a personal token. |
| Permissions | The same five scopes, ticked on the approval page. runs:write (launching, which spends on your provider keys) and runs:publish (publishing to your profile in your name) are never ticked for you. |
| What it sees | Your account’s id, handle and plan, and what its permissions reach. Never your email address, password or model keys. |
| Allowance | It counts toward the plan’s access tokens, like a personal token. Approving it again from the same app replaces its earlier connection; an app that registered anew (after you removed and added the server again, say) is a second connection, so disconnect the old one under Account > Developer. |
| Lifetime | Its access token lasts an hour and renews on its own; 30 days without use, the connection lapses. |
| Disconnecting | Account > Developer lists connected apps; Disconnect ends access at once. An app can also sign itself out. Sign out everywhere and a password reset by email link disconnect every app. |
| A copied token | Each renewal replaces the renewal token. A renewal token used again after it was replaced disconnects the app and emails you, since it can mean someone else holds a copy; an identical retry within 30 seconds (an answer lost on the way) is never taken for a copy: it gets the same answer, or, if a deploy moved it to a new server, is refused without disconnecting and the app asks you to approve it again. |
For client authors: OAuth 2.1 authorization code with PKCE (S256 only), dynamic client registration (RFC 7591) at /oauth/register, protected resource metadata (RFC 9728) at /.well-known/oauth-protected-resource/mcp/studio, authorization server metadata (RFC 8414) at /.well-known/oauth-authorization-server, resource indicators (RFC 8707) and revocation (RFC 7009) at /oauth/revoke. Public clients (token_endpoint_auth_method: none) and confidential ones (client_secret_post, client_secret_basic) are both accepted. Redirect URIs: https to any host but this one, http only to localhost, 127.0.0.1 or [::1] (where only the port may change, per RFC 8252), or the app’s own scheme; no fragment; up to 10, at most 512 characters each and 2,048 in all. A malformed authorization request shows the person a page with a link back to the app instead of redirecting on its own. A request to /mcp/studio without a credential answers 401 with a WWW-Authenticate header naming the resource metadata; an expired, revoked or unknown token answers the same with error="invalid_token".
| Sign-in step | Limit |
|---|---|
| Approval request | The approval page is good for 20 minutes and takes one decision. Across a deploy it may take a second: an approval then replaces any connection the first made, and a denial does not undo an earlier approval (disconnect under Account > Developer). |
| Authorization code | 5 minutes, single use, and only while the browser session that approved it is still signed in. A code used twice on the server that issued it disconnects the connection it made; across a deploy the second use is only refused. |
| Access token | 1 hour. |
| Refresh token | 30 days, renewed on each use, and rotated on each use: store the new one. An identical retry within 30 seconds gets the same answer (during a deploy it may be refused instead, without disconnecting); after that, the old token cuts the connection off. A refresh may send scope to narrow the access token, and a write permission keeps its read; widening answers invalid_scope. |
| Registration | 60 an hour per address. A registration unused for 30 days lapses, and one never used may go sooner when unused registrations pile up; register again when the server answers invalid_client. |
| Rate limits | Registration answers 429 past 60 an hour per address, and the token and revocation endpoints past 120 a minute, each with error: "too_many_requests" and a Retry-After header giving the seconds until the limit resets. |
A client configured with a fixed Authorization header keeps sending it: when that personal token expires or is revoked, the server answers the 401 above, and a client that supports sign-in may then open the approval page, but its fixed header still wins over the signed-in token. Replace the token in the header, or remove the header and sign in.
#Scopes
A scope is a hard boundary. A call outside the token’s scopes answers 403 scope_required whatever the plan: an agent holding a token without runs:write cannot launch, and one without runs:publish cannot publish, no matter what it is told.
| Scope | Allows | Implies |
|---|---|---|
scenarios:read | List and read your scenarios and skills, the schema, the library, the anchors and the Studio’s templates; validate a definition. | |
scenarios:write | Create, update and delete scenarios and skills. | scenarios:read |
runs:read | List and read your runs, batches, experiments and run sets and their results, the Models view and the meter; estimate a run or an experiment. | |
runs:write | Launch and cancel runs and experiments, and build run sets from finished runs. Spends money on your own model keys, so it is off by default. | runs:read |
runs:publish | Publish your runs and run sets to your public profile and take them off it, and write the notes shown there as yours: a run’s write-up, an experiment’s declared result and a run set’s note, with the switch that prints what its seats were told. Off by default and never part of runs:write, so a token that may launch cannot publish or speak for you unless you ticked this too. | runs:read |
#What a token can never do
Mint another token, change the account, read or write stored provider keys, touch billing, or reach another account’s scenarios and runs. Ids from other accounts read as unknown. Those actions stay behind the signed-in session in the Studio.
#Expiry and revocation
A token past its expiry, or revoked, answers 401 token_required from that moment; on the MCP server that is an HTTP 401 before any tool runs (see Errors). Revocation is immediate; there is no grace period. The Developer card revokes one token; Sign out everywhere and a password reset by email link revoke every token on the account and disconnect every connected app, while changing the password from a signed-in session revokes none. The card shows when each token was last used, so an idle one is easy to spot and retire.
#Rate limits
Each token has a per-minute ceiling set by the plan (see Plans and limits); a connected app has one ceiling for the connection, however often its access token renews. Above it, calls answer 429 rate_limited until the minute rolls, with a Retry-After header giving the seconds left. On the MCP server only tool calls and resource reads count, and a refused tool call is a tool error carrying rate_limited. Unauthenticated and refused requests are limited per address as well, so a misconfigured client cannot hammer the sign-in surface.
#Security events
Minting and revoking a token, and connecting and disconnecting an app, each write a security event on the account; minting a token and connecting an app also email the account a notice, so a credential you did not create is visible the moment it appears.