How sign-in works

You never paste an API key into an AI assistant to use the Whippy MCP server. The assistant signs you in with OAuth instead:

You add https://api.whippy.co/mcp to the assistant.
The assistant opens a Whippy sign-in page in your browser.
You sign in (SSO and MFA work as usual), choose a workspace if you belong to more than one, and approve the connection.
Whippy sends the assistant an access token for that workspace. The assistant refreshes it automatically.

The connection then appears on your Connected apps page, where you can disconnect it at any time.

🚧
API keys do not work on the MCP server
/mcp only accepts OAuth access tokens. A Whippy API key sent as a bearer token or in X-WHIPPY-KEY is rejected with 401. Use API keys with the REST API instead.

What the token can do

An access token is tied to three things:

You. Tools run as your Whippy user, with your role and permissions. If you can't do something in the Whippy app, the assistant can't do it either.
One workspace. The token only works in the workspace you picked during sign-in. To use another workspace, add the server a second time and pick that workspace.
The scopes you approved. See OAuth scopes.

For client developers

Most people can skip this section. It describes the standards-based flow for anyone building or debugging an MCP client.

The server follows the MCP authorization specification:

An unauthenticated request to https://api.whippy.co/mcp returns 401 with:

WWW-Authenticate: Bearer resource_metadata="https://api.whippy.co/.well-known/oauth-protected-resource"

The protected resource metadata (RFC 9728) names https://api.whippy.co as the authorization server.
The client reads https://api.whippy.co/.well-known/oauth-authorization-server (RFC 8414).
The client registers itself at the registration endpoint (RFC 7591) and runs the authorization code flow with PKCE.

Metadata	Value
`issuer`	`https://api.whippy.co`
`authorization_endpoint`	`https://api.whippy.co/oauth/authorize`
`token_endpoint`	`https://api.whippy.co/oauth/token`
`registration_endpoint`	`https://api.whippy.co/oauth/register`
`revocation_endpoint`	`https://api.whippy.co/oauth/revoke`
`introspection_endpoint`	`https://api.whippy.co/oauth/introspect`
`grant_types_supported`	`authorization_code`, `refresh_token`
`response_types_supported`	`code`
`code_challenge_methods_supported`	`S256`
`token_endpoint_auth_methods_supported`	`none` (public clients, no client secret)
`scopes_supported`	The 62 scopes listed in OAuth scopes

Dynamic client registration

POST /oauth/register creates a public PKCE client. It requires client_name and a non-empty redirect_uris array, and returns a client_id. No client secret is issued.

curl -X POST https://api.whippy.co/oauth/register \
  -H "Content-Type: application/json" \
  -d '{
    "client_name": "My MCP client",
    "redirect_uris": ["http://localhost:8787/callback"]
  }'

🚧
Redirect URIs must be on Whippy's allow-list
Registration only accepts these redirect URIs:

https://claude.ai/api/mcp/auth_callback

https://chatgpt.com/connector/oauth/*

cursor://anysphere.cursor-mcp/oauth/callback

https://www.cursor.com/agents/mcp/oauth/callback

https://api.devin.ai/mcp/oauth/callback

https://grok.com/connectors-oauth-exchange-code/ (with or without the trailing slash)

https://vscode.dev/redirect and https://insiders.vscode.dev/redirect

http://localhost:8787/callback

http://127.0.0.1:8765/auth/callback (Windsurf)

http://127.0.0.1:33418/ and http://127.0.0.1/ (VS Code)

Any other redirect URI fails with 400 invalid_redirect_uri. A local client works if it can receive its callback on exactly http://localhost:8787/callback. If you need a different callback, contact [email protected].

Refresh tokens

The token endpoint issues a refresh token with the access token, and public clients can use it (grant_type=refresh_token). Whippy does not advertise an offline_access scope, and clients don't need to request one.