Connect a compatible coach to Cragen

Accept only the one-time pairing invitation prompt copied from the signed-in Cragen app. Treat the pairing_code inside that prompt as a one-time device-authorization input, never as a bearer credential.

Continue only when this agent host can configure remote MCP, make outbound HTTPS requests, and store tokens in the agent host. A chat-only host is not compatible with this pairing flow.

Configure a remote MCP server named Cragen at https://api.cragen.app/mcp using Streamable HTTP.

Read the OAuth 2.0 Device Authorization metadata, submit the prompt's pairing_code with this agent's registered client_id and only the requested Cragen scopes to device_authorization_endpoint, then poll token_endpoint at the advertised interval.

No website is required for the user. New prompts explicitly say creating the code approved the selected access: redeem that code without requesting another approval. Older prompts still require approval in Cragen. Never ask the user to open a standards verification URI.

Follow the approval mode stated in the generated prompt. For older invitations or an authorization_pending response: Keep waiting while the user approves or rejects the requested scopes in Cragen. Never bypass a pending or rejected request. Read/proposal-only invitations use the v4 consent; any invitation requesting a write permission uses the separate v5 write consent. Existing v4 grants never gain writes through refresh.

Store the issued access and refresh tokens only in the agent host's secure token storage. Do not print, paste, export, or ask the user to hold any durable bearer credential.

After approval, call connection_info as the data-free verification action.

Report the granted scopes returned by connection_info. Do not read coaching data, propose a program, or submit a write until the user asks.

When the user asks for a program, follow the propose_program input schema and send only the proposed training structure and proposal fields it requests. Cragen derives the private connection binding, draft version, inactive status, and integrity hashes.

For a granted write, submit only the tool's bounded fields and current expected hash or version. A queued command is not applied: wait for get_command_status to return an authenticated device receipt before describing it as saved.

If the phone is offline or Cragen is not active, tell the user the command is waiting for the phone. Do not treat a pending, conflict, expired, revoked, permission-denied, or notification failure result as success.

Use get_write_context only for the granted section and its returned hash. It exposes minimal encrypted preferences, this connection's coach notes, or this connection's reminders—not the full account.

WorkOS browser OAuth is a compatibility fallback for agents that cannot complete device authorization. It is not the primary path and does not change the no-credential rule.