Identifiers
Discovery and endpoints
An unauthenticated request returns401 with an RFC 9728 WWW-Authenticate challenge naming the protected resource metadata document, which names the authorization server.
The step from
mcp.wavix.com to app.wavix.com is a metadata pointer the client resolves itself, not an HTTP redirect.
Client registration
Dynamic Client Registration (RFC 7591) is enabled and open: a client registers itself athttps://app.wavix.com/oauth/register with no initial access token and no prior arrangement with Wavix. Clients that publish a client-ID metadata document are supported alongside it.
Registration alone grants nothing. Every token still requires a Wavix user to complete the consent screen, and mandatory PKCE plus exact redirect_uri matching bound what a registration can do. A client registering a plaintext http:// loopback redirect URI is treated as a native application, so the callback matches on any port; every other component must match exactly.
Authorization request
Token lifetimes
Refresh tokens rotate: each refresh invalidates the token presented. A replayed authorization code revokes the grant.
Scopes
The Wavix MCP server advertises 27 scope values: 13 permission groups, each with:read and :write, plus offline_access. A :write grant includes read access to the same group.
offline_access is not a permission group and does not appear on the consent screen. It requests a refresh token.
Permission levels
A grant assigns each group No access, Read, or Write — the same three levels a restricted API key uses. There is no higher level: an OAuth grant can never exceed write on any group.Scopes are bounded by the user’s permissions
A scope is grantable only if the user’s own account permissions allow it, and granted scopes are intersected with those permissions again on every request. Most groups map to one account permission. Three require several, and are grantable only when the user’s role permits all of them:webhooks and embeddable have no account permission counterpart and are grantable to any authenticated user.
How scopes are enforced
- Tool listing. A tool the granted scopes do not cover is omitted from
tools/listand is not visible to the agent at all. - Tool call. A call from a stale tool list is refused with an MCP-level tool error inside a
200response, not an HTTP status. The message names the missing scope. - API gateway. A request reaching the Wavix API without a covering scope is refused with
403.
/v1/api-keys) match no scope rule and are denied to every OAuth token by design, so their tools are hidden from all OAuth connections. A connection authenticated with a Wavix API key is not scope-filtered: it sees the full catalogue, and the Wavix API enforces that key’s own scopes.
Revocation
Revocation is immediate. OAuth tokens bypass the gateway’s authorization cache, so the grant’s state is re-read on every request rather than at token expiry.