Connect Claude to Okta

List the people in the org, newest first, with each one's id, status, profile and sign-in timestamps. This is the entry point for the user side: get_user, list_user_app_assignments and list_user_factors all take the id returned here. Use `filter` for an exact, indexed expression over status, id, type.id, and the profile's firstName, lastName, login and email - for example "status eq \"ACTIVE\"" or "profile.email eq \"[email protected]\"". Use search_users instead for a broader expression that covers custom profile attributes. Paging is by the `after` cursor Okta returns in its Link header, not by an offset.

Fetch one person by id, login, or login shortname, with their full profile, status and sign-in timestamps. Okta accepts an email address here as well as an id, so this is the way to answer "who is [email protected]" without a search first. The status values that matter are ACTIVE, PROVISIONED, STAGED, RECOVERY, PASSWORD_EXPIRED, LOCKED_OUT, SUSPENDED and DEPROVISIONED.

Search people with an expression that reaches custom profile attributes and supports sorting, which the plain `filter` on list_users does not. `search` takes an SCIM-style expression such as "profile.department eq \"Engineering\"", "profile.lastName sw \"Do\"" or "status eq \"ACTIVE\" and lastUpdated gt \"2026-01-01T00:00:00.000Z\""; `q` is the simpler alternative that matches the beginning of firstName, lastName or email. Give one or the other, not both. Search results in Okta are eventually consistent, so a person created seconds ago may not appear yet - use get_user when the id or login is already known.

List the org's groups with each one's id, name, description, type and member count. Groups are how application access is handed out in bulk, so this is the map of who can reach what before any individual person is looked at. `type` is OKTA_GROUP for groups managed in Okta, APP_GROUP for groups imported from an application, and BUILT_IN for Everyone. Narrow with `q` (starts-with on the group name), `filter` (indexed properties) or `search`; pass expand=stats to include the member count.

Fetch one group by id, with its name, description and type. Read it to confirm which group an id refers to before calling list_group_members, which returns the people in it.

List the people in one group, with each one's id, status and profile. This is the answer to "who can reach the applications this group grants". Paging is by the `after` cursor from the previous response's Link header; a large group needs several calls.

List the applications configured in the org, with each one's id, label, sign-on mode and status. This is the inventory of what Okta federates into - the SAML and OIDC integrations, the SWA apps, and the bookmarks. Use `filter` for the indexed properties, which are the only ones Okta will filter on here: "status eq \"ACTIVE\"", "user.id eq \"00u...\"", "group.id eq \"00g...\"" and "credentials.signing.kid eq \"...\"". Filtering by group id is how to answer "what does this group actually grant".

Fetch one application by id, with its sign-on mode, settings and lifecycle state. Use it after list_applications to read how a single integration is configured - the SAML assertion settings, the OIDC redirect URIs, the visibility rules. Client secrets are not returned by this endpoint and this connector exposes no operation that returns one.

List the applications one person can actually reach - the tiles on their Okta dashboard - with the application id, label and sign-on URL of each. This is the per-person answer to "what does this account have access to", and it is the call to make when reviewing a leaver or an escalation. It resolves both direct assignments and the ones inherited from a group, which list_applications filtered by group.id cannot do on its own.

Read the org's System Log - who signed in from where, what failed, which admin changed what, and when. This is the operation to reach for after a suspicious sign-in or an unexplained configuration change. `filter` is Okta's indexed SCIM expression over eventType, target.id, actor.id and outcome.result, e.g. "eventType eq \"user.session.start\" and outcome.result eq \"FAILURE\""; `q` is a plain keyword match across the record. Always give `since` - without it Okta returns the last seven days and pages forever. Timestamps are ISO 8601 with milliseconds, e.g. 2026-08-01T00:00:00.000Z.

List one person's enrolled authentication factors, with the type, provider and status of each. This answers "does this account have a second factor, and what kind" - the question behind most access reviews and most compromised-account triage. The factor's `profile` is deliberately not returned: it holds the enrolled phone number or email address, and the answer to the question does not need it. Nothing here can enrol, reset or unenrol a factor; this connector has no writes at all.

Read the org's own settings - company name, subdomain, status, support contact and creation date. It is the cheapest call an API token can make and takes no arguments, which is why it is what an install runs to prove the token and the org domain are both right. It returns the account's own configuration and no personal data, so unlike most reads here its response is kept in the audit log.