Okta Workspace MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| okta-startB | Canonical startup flow: configure Browser Session or OIDC/OAuth on first use, reuse saved setup on later calls, and begin authentication. Set reconfigure=true only when the user explicitly wants to change setup |
| okta-resetA | Reset this MCP to its fresh-install state for an authorized demonstration: close the live browser, cancel pending OAuth, clear saved mode/tenant and local OAuth cache, and make the next okta-start show the authentication configuration form |
| okta-statusA | Show the selected authentication mode, configured tenant, connection state, and latest redacted proofs |
| okta-browser-session-proofB | Open or reuse a live isolated browser, authenticate to the configured tenant, and publish redacted cookie proofs at authentication and every five minutes while the session remains active |
| okta-browser-statusA | Show the live isolated browser state, current same-origin page, authenticated identity, and proof schedule without exposing cookies |
| okta-browser-snapshotA | Read a sanitized snapshot of the authenticated Okta page: title, headings, visible text, and controls without input values, cookies, tokens, or arbitrary JavaScript |
| okta-browser-navigateA | Navigate the visible isolated browser to a URL or path on the configured Okta origin; cross-origin navigation is rejected |
| okta-browser-readA | Perform a read-only GET from the authenticated browser to a same-origin /api/v1/ path; sensitive token, cookie, password, secret, and credential fields are redacted |
| okta-browser-refresh-proofB | Immediately publish a fresh authenticated browser proof to the loopback collector with every cookie value redacted |
| okta-browser-harvest-tokensA | Silently harvest OAuth tokens from all assigned public OIDC apps using prompt=none and PKCE, and store them in the collector at /v1/tokens |
| okta-browser-closeA | Close the live isolated Okta browser and delete its temporary profile |
| okta-oauth-loginC | AUTHORIZED LAB: authenticate through the configured Okta OIDC client with Authorization Code and PKCE |
| okta-oauth-reuse-proofB | AUTHORIZED LAB: demonstrate bearer-token reuse with two read-only UserInfo calls and publish only a SHA-256 token fingerprint |
| whoamiA | Show the connected OIDC user's verified Okta identity and granted scopes |
| userinfoA | Fetch the connected OIDC user's profile from Okta UserInfo |
| token-detailsA | Show safe token metadata without returning bearer values |
| my-groupsB | Show group names from the verified ID-token groups claim when configured |
| my-appsA | List application links assigned to the connected user (requires okta.users.read) |
| list-usersB | List users visible to the connected Okta administrator (requires okta.users.read) |
| get-userA | Get one user visible to the connected Okta administrator (requires okta.users.read) |
| search-usersA | Search users visible to the connected Okta administrator (requires okta.users.read) |
| list-groupsC | List groups visible to the connected Okta administrator (requires okta.groups.read) |
| list-appsB | List applications visible to the connected Okta administrator (requires okta.apps.read) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 23 tools
Several clusters have overlapping purposes, especially the auth/proof tools and identity/status tools such as whoami, userinfo, token-details, and okta-status. The descriptions are detailed enough to usually disambiguate, but similar names like my-apps vs list-apps and okta-browser-session-proof vs okta-browser-refresh-proof create some misselection risk.
Naming conventions are mixed: some tools use okta-* prefixes, others are bare names like whoami, userinfo, and token-details, and admin tools follow list/get/search patterns. The okta-browser-* and okta-oauth-* subgroups are helpful, but the overall naming is not predictable.
With 23 tools, the server is in the heavy range and covers a broad set of Okta workflows. The count is not unreasonable, but some tools could be consolidated, particularly around browsing, proof refresh, and identity lookup.
The authentication lifecycle and read-only directory access are well covered, including browser proofs, OAuth lab flows, userinfo, and user/group/app listing. However, there are notable gaps for an Okta workspace server: no create/update/delete operations for users, groups, or apps, and no token revocation or logout beyond reset/browser close.