What does an Okta MCP server for IT admins change?
It changes who a call runs as and what a single tool call can do. It does not change what your directory holds, and it cannot widen anyone's rights inside the identity system itself.
Your help desk lives in the identity admin console. Who is locked out, which groups this contractor holds, who was deprovisioned last Tuesday. Someone asks whether they can just ask Claude instead, and the search "okta mcp server for it admins" returns vendor pages, GitHub repositories and blog posts that do not agree with each other.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.
Three things decide what one identity tool call can actually do. The credential the connection was made with. The person the call acts as. And whether a rule in your control plane lets that tool run at all.
In Elaichi, every connected-tool call runs as one specific person, never as the organization at large. Over MCP that person is whoever approved the OAuth grant behind the client's token. A grant is the approval one named client gets, once, from one person in a browser. A connection shared with a teammate still runs on the connection owner's sign-in to the third-party app. So "the assistant acts with each admin's own rights" is true only when each admin connected their own account.
Does Okta publish an MCP server of its own?
This post makes no claim either way, and neither should a rollout plan. Elaichi's vendor notes carry no Okta page, so the honest step is to read Okta's own documentation, ask your Okta account team, and write the date next to the answer you get.
It matters less than it looks, because both shapes land in the same place in a governed catalog.
A native MCP connector is the vendor's own MCP server. The vendor builds and runs the server and its tools, and Elaichi handles sign-in, access and audit in front of it. Members connect with their own sign-in at the vendor. The credential sits in Elaichi's separate credential service, and the AI client only ever holds an Elaichi token. By default, a tool the vendor's server does not mark read-only or non-destructive counts as destructive.
The other shape is your own remote MCP server. On Gold, an Org Owner or Org Admin with the connector:create permission can add a remote MCP server as the organization's own connector. The server has to speak MCP over Streamable HTTP and be reachable over public HTTPS. The URL must use https and name a host, with no IP literal, no internal hostname and no embedded credentials, and it cannot be edited later. A different server means a new connector.
Start with the Okta connector page and the wider connector catalog to see what is already there. Running a vendor's MCP server through Elaichi covers the governance that wraps it either way.
Why an identity connection carries more risk than a ticketing one
A tool that creates a user or changes group membership is a path into every application that directory governs. A ticketing tool that goes wrong writes a bad comment. An identity tool that goes wrong hands someone a group.
That makes the restriction layer the real work, and it has two shapes that behave very differently.
In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. Keeping a help desk off a tool therefore means writing the rule on their role, or on each person. A block rule matches a tool by name or by the operation it performs, so renaming a tool cannot slip it past a block. An allow rule matches only the operation pinned when the rule was saved.
The first trap is that a layer with only block rules has no allowlist. Everything it does not name passes. Blocking two write tools on an identity connector leaves every write tool you did not think of reachable.
The second trap runs the other way. An allow rule turns the allowlist on for its whole layer just by existing. Once the help desk role carries any allow rule, every connector and tool that none of its allow rules names is blocked, across the whole catalog. An allow list for the identity connector therefore needs whole-connector allow rules for every other app that role uses.
Restriction changes are not instant. Count on them taking effect within about two minutes. Why blocks match tool names but allows do not goes further into the matching, and restricting one tool or the whole app walks the choice between the two shapes.
Setting it up, in order
Work from the credential outward. Each step below narrows what the next one can reach.
Pick the account first. Connect with the narrowest identity account that answers the lookups the help desk actually makes, not a super admin. Every call through that connection uses that account, for the owner and for everyone the connection is shared with.
Add the connector next, from the catalog if it is there, or as your own remote MCP connector on Gold if it is not. Then write the restriction on the help desk role before anyone connects a client, so nobody sees a tool you intend to take away.
Decide who reaches the connection. Sharing the connection at use gives each grantee the owner's account. The alternative is keeping the connection unshared, pinning it into a toolbox entry, and sharing the toolbox instead. A toolbox entry can carry frozen parameters, locked argument values the AI client cannot change. The client can see that they are set, and often what they are; it just cannot override them.
What the help desk sees in Claude or ChatGPT
A short tool list, not a directory of your apps. In Elaichi, connected tools are never listed one by one, however few there are. The model finds one with search_tools and runs it with execute_tool, and with run_code where Code Mode is listed.
Every client signs in at the same address, https://api.elaichi.ai/mcp. Each person connects once, approves their own consent screen and picks the organization the grant covers.
Where that address goes differs by client. On Claude Team and Enterprise plans, an Owner or Primary Owner adds a custom connector from Organization settings > Connectors (Anthropic's own guide, checked October 2026). They click Add, hover over Custom and choose Web. On ChatGPT Business, only admins and owners can enable developer mode and deploy a custom MCP app (OpenAI's developer mode article, checked October 2026). Cursor reads MCP servers from .cursor/mcp.json in a project and from ~/.cursor/mcp.json in the home directory, and supports OAuth for servers that require it (Cursor's MCP docs, checked October 2026).
A tool a restriction blocks is not hidden from the person. search_tools names it, flagged as restricted, with no schema and no way to call it, and a connector blocked whole shows as a single row. From the client the person can file their own access request. An admin resolves it in the console under Governance to Access requests, which needs the member:manage permission and a step-up confirmation. No AI surface can approve one.
Before an identity connector goes live, check two things.
First, no consent checkbox holds a client to reading a connected app. "Run your connected tools" covers every tier, deletes included. "Delete data and remove access" covers Elaichi's own deletes, not the app's. Holding a client to reads means picking toolboxes of read tools at consent, or blocking the write tools with a restriction.
Second, a client-side permission that gates individual MCP tools sees Elaichi's connected tools as one execute_tool. It cannot tell your identity system from your ticketing system. Per-app and per-tool control belongs in Elaichi.
The trade-off that follows: over MCP, Elaichi does not ask per call. The grant is the approval, chosen once on the consent screen for that named client. Any per-call confirmation the person sees is their own client's prompt. For an identity connector, that is a good argument for keeping writes out of the role entirely.
What the audit log holds afterward
Every connected-tool call that reaches execution writes a row. It records the person, the tool's advertised and catalog names, the connector, the connection the call actually reached, the tool's classification, how approval was given, the surface, the MCP client's id, and the outcome. A call refused earlier, by a missing scope or a restriction, writes no row, because nothing executed.
Elaichi keeps 90 days of audit history. For a longer trail, export to your own Datadog comes with the Black plan, which is launching soon.
Offboarding is the question an identity team asks next. Removing or suspending a member revokes their MCP grants in that organization, and their clients fail on the next call rather than when the token expires. Reactivating them does not bring the grants back; they consent again. What removal does not do is deactivate their accounts in the connected apps. That still happens in each app, or through your identity provider. Offboarding when the agent holds access covers the rest of the estate.
When the answer is no connector at all
If your help desk is three people who already have the admin console open all day, and nobody has asked for this, do not build it. The connector earns its keep when lookups are spread across several apps and several people, not when one console answers everything.
And if what you actually want is your identity provider as the sign-in for Elaichi, that is single sign-on rather than a connector. Elaichi implements SAML and OIDC itself, with no third-party identity vendor in the sign-in path, plus SCIM provisioning and group-to-role mappings, all included on Gold. A verified domain can enforce SSO for every address on it. Where SCIM stops and MCP grants begin is the post for that distinction.
From here, MCP governance is the wider picture of who may do what in which app, Jamf in Claude on a read-only role is the closest sibling playbook for an IT team, and the governance use case shows the controls side by side.
