Okta
## :tada: __It's Official__ :tada: The Okta Open-Source MCP Server integrates with LLMs and AI agents, allowing you to perform various Okta management operations using natural language and is Generally Available (GA).
6.2K
108 Tools
Packaged by
Requires Secrets
Add to Docker Desktop
Version 4.43 or later needs to be installed to add the server automatically
Tools
| Name | Description |
|---|---|
list_applications | List all applications from the Okta organization. |
get_application | Get an application by ID from the Okta organization. |
create_application | Create a new application in the Okta organization. |
update_application | Update an application by ID in the Okta organization. |
delete_application | Delete an application by ID from the Okta organization. This tool deletes an application by its ID from the Okta organization. The user will be asked for confirmation before the deletion proceeds. |
confirm_delete_application | Confirm and execute application deletion after receiving confirmation. .. deprecated:: This tool exists for backward compatibility with clients that do not support MCP elicitation. New clients should rely on the built-in elicitation prompt in ``delete_application`` instead. This function MUST ONLY be called after the human user has explicitly typed 'DELETE' as confirmation. NEVER call this function automatically after delete_application. |
activate_application | Activate an application in the Okta organization. |
deactivate_application | Deactivate an application in the Okta organization. |
list_brands | List all brands in the Okta organization with pagination support. |
get_brand | Retrieve a specific brand by its ID. |
create_brand | Create a new brand in the Okta organization. A brand controls the look-and-feel of the sign-in page, error pages, email templates, and the End-User Dashboard. After creation you can customise it further with ``replace_brand`` and the Themes API. |
replace_brand | Replace (fully update) a brand by its ID. This is a full replacement (HTTP PUT). Every writable field in the brand will be overwritten — omitted optional fields revert to their defaults. |
delete_brand | Delete a brand by its ID. The user is asked to confirm before the deletion is carried out. The default (Okta) brand cannot be deleted — the API will return a 409 error in that case. |
list_brand_domains | List all custom domains associated with a brand. Each brand can have one or more domains. The default Okta subdomain (e.g. ``yourorg.okta.com``) is always present; additional custom domains appear here once they have been verified and activated. |
list_custom_domains | List all custom domains in the Okta organization. Returns all custom domains including the default Okta subdomain (id: ``"default"``). The API does not support pagination — all domains are returned in a single response. Each domain object includes: - ``id`` – Unique domain ID (``"default"`` for the org base domain). - ``domain`` – The fully qualified domain name. - ``brandId`` – ID of the brand associated with this domain. - ``certificateSourceType``– ``"MANUAL"`` or ``"OKTA_MANAGED"``. - ``validationStatus`` – ``NOT_STARTED`` | ``IN_PROGRESS`` | ``VERIFIED`` | ``COMPLETED`` | ``FAILED_TO_VERIFY``. - ``dnsRecords`` – DNS records to configure at your DNS provider (TXT + CNAME, present until domain is verified). - ``publicCertificate`` – Certificate metadata (present after verification). |
create_custom_domain | Create a new custom domain for the Okta organization. After creating a domain, the response includes DNS records (TXT + CNAME) that you must configure at your DNS provider before calling ``verify_custom_domain``. Okta does not automatically verify domains. |
get_custom_domain | Retrieve a custom domain by its ID. |
replace_custom_domain | Replace the brand associated with a custom domain. Associates a different brand with the given custom domain. The brand controls the look-and-feel of the sign-in page and email templates served under that domain. Constraints: - The default brand (``isDefault: true``) cannot be mapped to a custom domain (API returns 409). - The PUT is allowed regardless of the domain's ``validationStatus``; the brand association can be changed at any point in the domain lifecycle. |
delete_custom_domain | Delete a custom domain by its ID. Permanently removes the custom domain from the organization. The default org domain (``id: "default"``) cannot be deleted. A confirmation prompt is shown before proceeding. |
upsert_custom_domain_certificate | Upload or renew the TLS certificate for a MANUAL custom domain. Creates or replaces the PEM-encoded certificate for a custom domain whose ``certificateSourceType`` is ``MANUAL``. If the domain is currently ``OKTA_MANAGED``, calling this switches it to ``MANUAL`` and Okta stops auto-renewing the certificate. Okta supports TLS certificates and private keys that are PEM-encoded and 2048, 3072, or 4096 bits. |
verify_custom_domain | Verify a custom domain by checking its DNS records. Triggers Okta to verify that the TXT and CNAME records you added at your DNS provider match the values returned when the domain was created. DNS changes can take time to propagate — if verification fails immediately after adding records, wait a few minutes and try again. After a successful verification: - ``validationStatus`` becomes ``VERIFIED`` (or ``COMPLETED`` once the certificate is also installed). - If ``certificateSourceType`` is ``OKTA_MANAGED``, Okta also provisions and installs a TLS certificate automatically. |
get_error_page_resources | Retrieve the error page sub-resource links for a brand. Returns navigation links (``_links``) for the customized, default, and preview error pages. Pass one or more values in ``expand`` to embed the full page content of those sub-resources inline in the response. |
get_customized_error_page | Retrieve the customized error page for a brand. The customized error page is what end-users see in the live environment when an error occurs. Returns 404 if no customization exists (the default page is in use). |
replace_customized_error_page | Replace (or create) the customized error page for a brand. Sets the HTML that appears in the live environment when an error occurs. Replaces the entire customized page; any fields omitted revert to their defaults. |
delete_customized_error_page | Delete the customized error page for a brand. Removes the customized error page so the Okta default error page is shown in the live environment. Requires explicit confirmation before proceeding. |
get_default_error_page | Retrieve the default (Okta-provided) error page for a brand. The default error page is shown when no customized error page exists. It cannot be modified; use ``replace_customized_error_page`` to override it. |
get_preview_error_page | Retrieve the preview error page for a brand. The preview page is a sandbox for testing error page changes before they go live. Returns 404 if no preview exists. |
replace_preview_error_page | Replace (or create) the preview error page for a brand. Sets the HTML for the error page preview environment. Use this to test changes before publishing to the live customized error page. |
delete_preview_error_page | Delete the preview error page for a brand. Removes the preview error page. The preview environment will fall back to the default error page. Requires explicit confirmation before proceeding. |
get_sign_in_page_resources | Retrieve the sign-in page sub-resource links for a brand. Returns navigation links (``_links``) for the customized, default, and preview sign-in pages. Pass one or more values in ``expand`` to embed the full page content of those sub-resources inline in the response. |
get_customized_sign_in_page | Retrieve the customized sign-in page for a brand. The customized sign-in page is what end-users see in the live environment. Returns 404 if no customization exists (the default page is in use). |
replace_customized_sign_in_page | Replace (or create) the customized sign-in page for a brand. Sets the HTML, widget version, and widget behaviour that appear in the live environment. The ``widgetCustomizations`` parameter lets you control labels, links, and toggles shown in the Okta sign-in widget. |
delete_customized_sign_in_page | Delete the customized sign-in page for a brand. Removes the customized sign-in page so the Okta default sign-in page is shown in the live environment. Requires explicit confirmation before proceeding. |
get_default_sign_in_page | Retrieve the default (Okta-provided) sign-in page for a brand. The default sign-in page is shown when no customized page exists. It cannot be modified; use ``replace_customized_sign_in_page`` to override it. |
get_preview_sign_in_page | Retrieve the preview sign-in page for a brand. The preview page is a sandbox for testing sign-in page changes before they go live. Returns 404 if no preview exists. |
replace_preview_sign_in_page | Replace (or create) the preview sign-in page for a brand. Sets the HTML, widget version, and widget behaviour for the sign-in page preview environment. Use this to test changes before publishing to the live customized sign-in page. |
delete_preview_sign_in_page | Delete the preview sign-in page for a brand. Removes the preview sign-in page. The preview environment will fall back to the default sign-in page. Requires explicit confirmation before proceeding. |
list_sign_in_widget_versions | List all available Okta Sign-In Widget versions for a brand. Returns the version strings that can be used in the ``widget_version`` parameter of ``replace_customized_sign_in_page`` and ``replace_preview_sign_in_page``. Includes both specific versions and range expressions. |
get_sign_out_page_settings | Retrieve the sign-out page settings for a brand. Returns the current sign-out page configuration, which controls where users are redirected after signing out. |
replace_sign_out_page_settings | Replace the sign-out page settings for a brand. Controls where users are redirected after they sign out. Set ``type`` to ``OKTA_DEFAULT`` to use the built-in Okta sign-out page, or ``EXTERNALLY_HOSTED`` to redirect users to a URL you provide. |
list_email_templates | List all email templates for a brand with pagination support. Returns every Okta-managed email template available on the brand. By default each entry contains only the template ``name`` and ``_links``. Use ``expand`` to embed additional metadata inline. |
get_email_template | Retrieve a single email template for a brand. Returns the named Okta email template with its navigation links. Pass ``expand`` to embed settings or customization count inline. |
list_email_customizations | List all customizations for an email template with pagination support. Returns every language variant that has been created for the specified email template. Each entry includes the full customization body, subject, language, ``isDefault`` flag, and timestamps. |
create_email_customization | Create a new language customization for an email template. Adds a new localized variant for the specified email template. Only one customization per language is allowed — creating a duplicate language returns a 409 Conflict error. The first customization created for a template automatically becomes the default (``isDefault=True``); subsequent ones default to ``False``. The ``body`` must be valid HTML and **must** include all required Okta template variables for the template type. For example, ``UserActivation`` requires ``${activationLink}`` or ``${activationToken}``. |
get_email_customization | Retrieve a specific email customization by its ID. Returns the full customization object including the HTML body, subject, language, ``isDefault`` status, and timestamps. |
replace_email_customization | Replace an existing email customization (full update). Replaces all fields on the specified customization. All required fields must be supplied; the operation is not a partial patch. The ``body`` must include all required Okta template variables for the template type or the request will be rejected with a validation error. |
delete_email_customization | Delete a specific email customization. Permanently removes the specified language customization from the email template. Requires explicit confirmation before proceeding. If this is the only customization (i.e. the default), you may need to delete all customizations instead; deleting the sole default customization may return an error — use ``delete_all_email_customizations`` in that case. |
delete_all_email_customizations | Delete ALL customizations for an email template. Permanently removes every language variant from the specified email template, reverting it to Okta's built-in default content. This is irreversible and cannot be undone. Requires explicit confirmation. |
get_email_customization_preview | Preview a rendered email customization. Returns the customization with all Okta template variables replaced by representative sample values. Useful for verifying how the email will appear to recipients before publishing. |
get_email_default_content | Retrieve the Okta default content for an email template. Returns the unmodified Okta-provided subject and body for the specified template. This is the fallback content shown when no customization exists for a given language. Useful for inspecting the baseline before creating a customization. |
get_email_default_content_preview | Preview the rendered Okta default content for an email template. Returns the Okta default subject and body with all template variables replaced by representative sample values. Unlike ``get_email_default_content``, all ``${variable}`` placeholders are substituted with real-looking data so you can see exactly what an end user would receive. |
get_email_settings | Retrieve the email settings for a template. Returns the recipient configuration for the specified email template, controlling which user populations will receive emails of this type. |
replace_email_settings | Replace the email settings for a template. Updates the recipient configuration for the specified email template. This controls who receives emails of this type across your Okta org. |
send_test_email | Send a test email for a template to the current API user. Triggers Okta to send a test version of the specified email template to the email address of the user associated with the current API token. If a customization exists for the requested language, the customized version is sent; otherwise the Okta default content is used. |
list_email_domains | List all email domains in the Okta organization. Returns every Email Domain configured in the org. Each domain shows its current validation status and the DNS records that must be published to complete verification. |
create_email_domain | Create a new email domain for the Okta organization. After creation the response includes DNS records (one TXT record and three CNAME records) that you must publish at your DNS provider. Call ``verify_email_domain`` once the records are live to complete setup. |
get_email_domain | Retrieve an email domain by its ID. |
replace_email_domain | Replace the sender display name and username for an email domain. Only ``display_name`` and ``user_name`` can be updated — the domain name itself and validation subdomain are immutable after creation. The domain's validation status and DNS records are preserved. |
delete_email_domain | Delete an email domain by its ID. Permanently removes the email domain from the organization. Any brands currently associated with this domain will revert to sending email from the default Okta sender address. A confirmation prompt is shown before proceeding. |
verify_email_domain | Verify an email domain by checking its DNS records. Okta looks up the DNS records that were returned when the domain was created and verifies that they are correctly published. On success the domain's ``validationStatus`` transitions to ``VERIFIED`` and Okta begins routing email through your custom sender address. Prerequisites: All four DNS records (one TXT + three CNAMEs) from ``dnsValidationRecords`` must be published at your DNS provider before calling this tool. DNS propagation can take up to 48 hours. |
list_brand_themes | List all themes for a brand. Currently each Okta org supports only one theme per brand, so this always returns a single-element list. |
get_brand_theme | Retrieve a specific theme by brand ID and theme ID. |
replace_brand_theme | Replace (fully update) a theme's colours and touchpoint variants. All five touchpoint variant fields are required. Optional fields default to ``null`` if omitted, which lets Okta auto-optimise contrast colours. |
upload_brand_theme_logo | Upload and replace the logo for a theme. The file must be in PNG, JPG, or GIF format and less than 100 kB. For best results use landscape orientation, a transparent background, and a minimum size of 300 × 50 px to prevent upscaling. |
delete_brand_theme_logo | Delete the custom logo for a theme. After deletion the theme falls back to the default Okta logo. This operation is reversible — you can re-upload a logo at any time. |
upload_brand_theme_favicon | Upload and replace the favicon for a theme. The file must be in PNG, JPG, or GIF format and less than 2 MB in size. |
delete_brand_theme_favicon | Delete the custom favicon for a theme. After deletion the theme falls back to the default Okta favicon. This operation is reversible — you can re-upload a favicon at any time. |
upload_brand_theme_background_image | Upload and replace the background image for a theme. The file must be in PNG, JPG, or GIF format and less than 2 MB in size. The background image is used by touchpoint variants that reference ``BACKGROUND_IMAGE``. |
delete_brand_theme_background_image | Delete the background image for a theme. After deletion the theme no longer has a background image. Touchpoint variants that referenced ``BACKGROUND_IMAGE`` will fall back to their default appearance. This operation is reversible — you can re-upload a background image at any time. |
list_device_assurance_policies | List all Device Assurance Policies in the Okta organization. Use this to audit which device assurance policies exist, compare OS version requirements across policies, find policies that do or do not block jailbroken/rooted devices, or identify policies whose platform requirements may be outdated. *** MANDATORY — OS VERSION THRESHOLD QUERIES *** Any time the user's request mentions a version number for filtering or comparison (e.g. "older than 14.2", "below 14.2.1", "at least 13.x"): 1. You MUST pass that exact user-supplied string as ``version_threshold``. WRONG: list_device_assurance_policies() ← bypasses validation RIGHT: list_device_assurance_policies(version_threshold="<user value>") ← always pass through NEVER call this tool with no arguments and then filter the result yourself — that completely bypasses format validation. 2. If the version is rejected (e.g. because the patch component is missing), relay the error word-for-word. STOP and ask the user: "What is the exact full version in X.Y.Z format?" Do NOT guess or complete the version yourself. Do NOT proceed until the user explicitly confirms the full X.Y.Z version. 3. NEVER guess or infer what the user "probably" meant — always ask. IMPORTANT — always call fresh: Never reuse results from a previous call to resolve a policy name to an ID. Always call this tool again to get an up-to-date list, as policies may have been created or deleted since the last call. The response includes a ``retrieved_at`` timestamp — if the user references a policy by name that does not appear in a previous list, you MUST call this tool again before concluding that the policy does not exist. IMPORTANT — intermittent empty response: If this tool returns an empty list but the user expects policies to exist, call it again — the API occasionally returns an empty response on the first call after server start. A retry will return the correct data. |
get_device_assurance_policy | Retrieve a specific Device Assurance Policy by ID. Use this to inspect the full configuration of a policy — platform type (ANDROID, IOS, MACOS, WINDOWS, CHROMEOS), minimum OS version, disk encryption requirements, biometric lock settings, jailbreak/root detection, and any other compliance checks configured in the policy. IMPORTANT — name-to-ID resolution: This tool requires a policy ID, not a name. If the user refers to a policy by name, you MUST call list_device_assurance_policies() first to get a FRESH, current list before resolving the name to an ID. NEVER resolve a policy name using results already present in the conversation — those results may be stale. Even if you called list_device_assurance_policies moments ago, call it again: a policy may have been created in the Okta UI between that call and now. Only after receiving the fresh list may you map the name to an ID and call this tool. |
create_device_assurance_policy | Create a new Device Assurance Policy. *** MANDATORY — OS VERSION *** If the policy requires a minimum OS version: a. Do NOT put osVersion inside policy_data — the tool constructs it from user_stated_os_version after validation. b. Set user_stated_os_version to the EXACT characters the user typed, verbatim. NEVER invent or complete the version. "12.1" and "12.1.0" are NOT the same — never append a patch number yourself. c. If user_stated_os_version is rejected, relay the error and ask: "What is the exact full version in X.Y.Z format?" Platform-specific attribute support: - ANDROID: name, platform, osVersion, jailbreak (false only), screenLockType - IOS: name, platform, osVersion, jailbreak (false only), screenLockType - MACOS: name, platform, osVersion, diskEncryptionType, screenLockType, secureHardwarePresent - WINDOWS: name, platform, osVersion, diskEncryptionType, screenLockType, secureHardwarePresent - CHROMEOS: name, platform, osVersion |
replace_device_assurance_policy | Replace (fully update) an existing Device Assurance Policy. *** MANDATORY RESPONSE FORMAT — YOU MUST FOLLOW THIS EVERY TIME *** This tool ALWAYS returns ``"before"``, ``"after"``, and ``"changes"`` fields. After every successful call you MUST: 1. Present a formatted before/after comparison table to the user. 2. For every entry in ``"changes"``, show the attribute name, old value, new value, and the ``"implication"`` string. 3. NEVER reply with just "Done" or a one-line summary. The user must see the full comparison — always. 4. OS VERSION — always use ``user_stated_os_version`` parameter: a. Do NOT put osVersion in policy_data — the tool derives it from user_stated_os_version after validation. b. Set user_stated_os_version to the EXACT characters the user typed, verbatim. NEVER invent or complete the version. "X.Y" and "X.Y.0" are NOT the same — never append a patch number yourself. c. If user_stated_os_version is rejected, relay the error — STOP and ask: "What is the exact full version in X.Y.Z format?" d. Do NOT call this tool until the user explicitly states the full X.Y.Z version. Use this to update minimum OS version requirements, change platform compliance settings, or standardise policy configurations across your organisation. Platform-specific attribute support: - ANDROID: name, platform, osVersion, jailbreak (false only), screenLockType - IOS: name, platform, osVersion, jailbreak (false only), screenLockType - MACOS: name, platform, osVersion, diskEncryptionType, screenLockType, secureHardwarePresent - WINDOWS: name, platform, osVersion, diskEncryptionType, screenLockType, secureHardwarePresent - CHROMEOS: name, platform, osVersion The response ALWAYS includes ``"before"`` and ``"after"`` state comparisons plus a ``"changes"`` list with security implications for each modified attribute. You MUST present this as a formatted confirmation summary to the user, showing exactly what changed and its security implication. Never simply say "Done" — always display the before/after comparison table. |
delete_device_assurance_policy | Delete a Device Assurance Policy from the Okta organization. The user will be asked for confirmation before the deletion proceeds. Note: A policy that is currently assigned to an authentication policy cannot be deleted. |
list_groups | List all the groups from the Okta organization with pagination support. If search, filter, or q is specified, it will list only those groups that satisfy the condition. |
get_group | Get a group by ID from the Okta organization This tool retrieves a group by its ID from the Okta organization. |
create_group | Create a group in the Okta organization. This tool creates a new group in the Okta organization with the provided profile. |
delete_group | Delete a group by ID from the Okta organization. This tool deletes a group by its ID from the Okta organization. The user will be asked for confirmation before the deletion proceeds. |
confirm_delete_group | Confirm and execute group deletion after receiving confirmation. .. deprecated:: This tool exists for backward compatibility with clients that do not support MCP elicitation. New clients should rely on the built-in elicitation prompt in ``delete_group`` instead. This function MUST ONLY be called after the human user has explicitly typed 'DELETE' as confirmation. NEVER call this function automatically after delete_group. |
update_group | Update a group by ID in the Okta organization. This tool updates a group by its ID with the provided profile. |
list_group_users | List all users in a group by ID from the Okta organization with pagination support. This tool retrieves all users in a group by its ID from the Okta organization. |
list_group_apps | List all applications assigned to a group with pagination support. |
add_user_to_group | Add a user to a group by ID in the Okta organization. This tool adds a user to a group by its ID in the Okta organization. |
remove_user_from_group | Remove a user from a group by ID in the Okta organization. This tool removes a user from a group by its ID in the Okta organization. |
list_policies | List all the policies from the Okta organization with pagination support. |
get_policy | Retrieve a specific policy by ID. |
create_policy | Create a new policy. |
update_policy | Update an existing policy. |
delete_policy | Delete a policy. The user will be asked for confirmation before the deletion proceeds. |
activate_policy | Activate a policy. |
deactivate_policy | Deactivate a policy. The user will be asked for confirmation before the deactivation proceeds. |
list_policy_rules | List all rules for a specific policy with pagination support. |
get_policy_rule | Retrieve a specific policy rule. |
create_policy_rule | Create a new rule for a policy. |
update_policy_rule | Update an existing policy rule. |
delete_policy_rule | Delete a policy rule. The user will be asked for confirmation before the deletion proceeds. |
activate_policy_rule | Activate a policy rule. |
deactivate_policy_rule | Deactivate a policy rule. |
get_login_failures | Investigate why a user failed to log in. Returns BOTH authentication failures AND policy-blocked sign-ins in one call. USE THIS TOOL (not get_logs) whenever the user asks about: - failed logins, login failures, sign-in problems - why a user can't log in / couldn't sign in - authentication errors, access denied - blocked logins, denied access - login issues, sign-in issues This tool automatically queries BOTH outcome types: - FAILURE: wrong password, invalid MFA, locked account, expired credentials - DENY: access blocked by sign-on policy (IP restriction, device trust, geo-fencing) A single get_logs call only returns ONE of these. This tool returns BOTH. |
get_logs | Retrieve system logs from the Okta organization with pagination support. This tool retrieves system logs from the Okta organization. IMPORTANT — context isolation: Each call is INDEPENDENT. Do NOT carry forward q, search, or filter values from a previous query unless the user explicitly asks to apply the same filter again. Example: if the user previously asked about user X and now asks "show me ALL failed logins", do NOT add q=<user_X_email> to the new call — that would silently scope results to user X only. IMPORTANT — fetch_all usage: By default (fetch_all=False) only the first page is returned (up to 100 entries). RULE: For ANY query about "all", "complete", "total", "how many", "list all", "show all", "every", or any query that does not explicitly ask for just the latest/most recent event, you MUST use fetch_all=True. Without it the result is INCOMPLETE and counts will be WRONG. ALWAYS pair fetch_all=True with a time window: since="...", until="..." Example: get_logs(fetch_all=True, filter='outcome.result eq "FAILURE"', since="2026-03-11T00:00:00.000Z", until="2026-03-12T00:00:00.000Z") If the user does not specify a time range, default to the last 24 hours. fetch_all is capped at 50 pages (5,000 entries). If stopped_early=True, tell the user to narrow their time window or add a more specific filter. CRITICAL — login failure investigation: FAILURE and DENY are TWO SEPARATE outcome values. A single call is NEVER sufficient. - FAILURE: authentication failures (wrong password, locked account, MFA not completed) - DENY: access blocked by a sign-on policy rule (IP/device/policy violation) You MUST ALWAYS make TWO separate calls when investigating login failures: 1. get_logs(filter='outcome.result eq "FAILURE"', fetch_all=True, ...) 2. get_logs(filter='outcome.result eq "DENY"', fetch_all=True, ...) Making only ONE call is a BUG — you will silently miss an entire category of failures. This applies to ALL prompts about: failed logins, sign-in issues, login problems, why a user can't log in, authentication errors, access denied, denied sign-ins, denied access, blocked logins, sign-in failures, access issues, etc. CRITICAL — MFA challenge queries: When the user asks about MFA challenges, MFA prompts, step-up auth, or authentication challenges, ALWAYS use filter='outcome.result eq "CHALLENGE"'. Do NOT use eventType filters or outcome.result eq "SUCCESS" for MFA challenges. Using SUCCESS or eventType is WRONG for challenges — it will return incorrect results. CRITICAL — invalid outcome value: If the user asks for an unrecognised outcome type (e.g. "INVALID_OUTCOME", "BLOCKED"): You MUST still call this tool with filter='outcome.result eq "<VALUE>"' and let the server return the error. Do NOT decide yourself that the value is invalid and skip the call or say "no events found". The server will return an error dict — you MUST read that error dict and relay the message to the user, explaining which values are valid. Never silently say "no events found" when the tool returns an error dict. |
list_users | List all the users from the Okta organization with pagination support. If search, filter, or q is specified, it will list only those users that satisfy the condition. Use after and limit for pagination. Use fetch_all=True to automatically fetch all pages of results. By default, it will only fetch users whose status is not "DEPROVISIONED". IMPORTANT — default page size: When limit is NOT provided, the server defaults to 20 users per page. ALWAYS omit the limit parameter unless the user explicitly requests a different page size. |
get_user_profile_attributes | List all user profile attributes supported by your Okta org. This is helpful in case you need to check if the user profile attribute is valid. The prompt can contain non existent search terms, in which case we should seek clarification from the user by listing most similar profile attributes. |
get_user | Get a user by ID from the Okta organization This tool retrieves a user by their ID from the Okta organization. |
create_user | Create a user in the Okta organization. This tool creates a new user in the Okta organization with the provided profile. |
update_user | Update a user in the Okta organization. This tool updates an existing user in the Okta organization with the provided profile. |
deactivate_user | Deactivates a user from the Okta organization. This tool deactivates a user from the Okta organization by their ID. The user will be asked for confirmation before the deactivation proceeds. Deactivating the user is a prerequisite for deleting the user. |
delete_deactivated_user | Delete a user from the Okta organization who has already been deactivated or deprovisioned. This tool permanently deletes a deactivated/deprovisioned user. The user will be asked for confirmation before the deletion proceeds. |
export_users_csv | Fetch all users from the Okta organization and save them to a CSV file on disk. Uses the same pagination logic as list_users (fetch_all=True) but writes results directly to a CSV file instead of returning them, avoiding response size limits. |