Authentication
The OAuth flow MCP clients use to authenticate against the Seal MCP server.
The Seal MCP server authenticates clients through OAuth, using the same identity provider that backs the Seal UI. Any MCP-aware client that supports OAuth can connect.
What the client needs
The Seal MCP server URL, available on your tenant's API page in the Seal UI.
The user's Seal credentials, used during the OAuth authorization flow.
Client identification
The Seal OAuth flow accepts both client-identification styles MCP clients use, so no extra registration is needed on your side:
Dynamic Client Registration. The client registers itself on first connect and receives a client ID.
Published client metadata. The client's ID is a URL pointing at its own metadata document.
Clients that do not declare their required scopes are given the standard OpenID Connect set (openid, profile, email, offline_access).
Loopback redirect URIs
Local MCP clients often listen on a free port that changes each launch. Following RFC 8252, the Seal MCP server accepts any port on a loopback redirect URI (localhost, 127.0.0.1, or ::1), so those clients connect without pinning a port. The scheme, host, and path must still match the registered value.
Per-tool permissions
Each tool requires a specific Seal permission on the calling user, enforced per call. Read-only tools (list_sealing_rules, list_projects, get_package_details, get_daily_analytics, and so on) need view; mutations require the matching write permission. See User roles for the role-to-permission mapping.
Tenant scoping
Every tool call is scoped to the calling user's tenant. There is no cross-tenant access.
Related
Last updated