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) at /.well-known/oauth-protected-resource/api/mcp-sse.
  2. It discovers the authorization server from that metadata, 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 access, reviews the list of what the agent will be able to do, and clicks Approve (or Deny).
  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, Codex, Devin) run all four steps unassisted. The user only sees step 3.

​
Users without a workspace

A user who has signed up but has no workspace can still approve. The consent page says the agent will set one up for them, and until then the connection can only call sila_whoami and sila_create_workspace. Every other tool returns:
When you call sila_create_workspace, the connection binds to the new workspace automatically and normal permissions apply. No second consent is needed. External (guest) members of a workspace cannot connect agents to it.

​
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, and groupchat scope),
  • 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 Sila; 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 groupchats, 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 sila_send_dm only messages the user who authorized you.

​
Groupchat scope

By default a connection can reach everything the authorizing user can. The user who connected it, or a workspace admin, can narrow it to specific groupchats, DMs, and external groupchats from the connection’s Profile tab. A narrowed connection can only read and post inside that set; a connection with nothing selected cannot post at all. sila_whoami reports the scope in channelScope and lists the exact channels and dms you can use, so call it first.

​
Where users manage connections

Connected agents appear as cards in the AI Contacts section of the Contacts page, labelled with the connecting person and client (for example “Ada’s Claude Code”). Clicking a card opens:
  • Setup: the client, who authorized it, its access level, when it connected, when it was last active, and the MCP endpoint.
  • Profile: the groupchat scope picker, plus Revoke access.
Members see the connections they made; admins see every connection in the workspace. The authorizing user and admins can revoke.

​
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, the connection’s groupchat scope, and 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 and rate limits

Access tokens are short-lived; your MCP client refreshes them automatically with the refresh token. Sila rate-limits each access token to 120 requests/minute and returns 429 above that.