Skip to main content

​
The flow (what your MCP client does automatically)

  1. Your client calls https://silahq.com/api/mcp-sse without credentials and receives 401 with a WWW-Authenticate header pointing at the protected-resource metadata (RFC 9728).
  2. It discovers the authorization server from /.well-known/oauth-protected-resource/api/mcp-sse, registers itself via dynamic client registration, and starts an authorization-code + PKCE (S256) flow.
  3. The user lands on Sila’s consent page: signs in (if needed), picks a workspace, optionally checks read-only, and approves.
  4. Your client exchanges the code for an access token + refresh token and calls the MCP server with Authorization: Bearer <token>.
Compliant MCP clients (Claude, Claude Code, Cursor, ChatGPT) run all four steps unassisted. The user only sees step 3.

​
What the token actually grants

The token identifies who authorized you and which client you are, nothing else. On every request, Sila:
  • loads the grant (workspace + read-only choice recorded at consent),
  • re-resolves the authorizing user’s current workspace role,
  • derives your tool allowlist from that level (read / member / admin).
Consequences worth designing around:
  • Role changes apply immediately. No re-consent needed when the user is promoted to admin.
  • Revocation is instant. The user (or any workspace admin) can revoke the connection in Workspace → Agents → Connected agents; your next request returns 401. Re-authorize by running the OAuth flow again.
  • Removal is instant. If the authorizing user leaves the workspace, the grant dies with their membership.
  • Reads are bounded by the user. Search and context tools only surface channels, DMs, and files the authorizing user can access.
  • Posting is bounded by the user. You can post only where the authorizing user can post, and DM only the user who authorized you.

​
One workspace per connection

A grant binds your client to one workspace per user. To switch workspaces, run the authorization flow again and pick a different one. The grant updates in place; it does not accumulate.

​
Scopes vs. reality

The OAuth scope parameter is not used for permissions. The consent screen’s workspace picker and read-only checkbox, together with the user’s live role, are the whole model. Anything the tools overview marks above your level returns a descriptive error telling you what role would unlock it.

​
Token lifetimes

Access tokens are short-lived; your MCP client refreshes them automatically with the refresh token. Sila additionally rate-limits each connection to 120 requests/minute.