WorkOS MCP Server

The WorkOS MCP Server connects an AI assistant to your WorkOS workspace. WorkOS is a platform that software teams use to build sign-in, single sign-on (SSO), directory sync, and audit logs into their products so that these become suitable for enterprise customers. The server takes work off you in the dashboard: instead of clicking through menus, you describe in chat or in the editor what you need, for example sending an invitation, investigating a faulty SSO connection, or creating a new organization with its users. The server is operated by WorkOS itself; according to the provider it was introduced in July 2026 as a management interface for AI agents.

What is the WorkOS MCP Server?

MCP, the Model Context Protocol, is an open standard through which AI assistants can call tools of external services. The WorkOS server is a hosted remote server at https://mcp.workos.com/mcp, reachable via Streamable HTTP. You install and run nothing locally. On the first connection a consent screen from WorkOS opens; sign-in works through OAuth with WorkOS Connect. After that the agent acts with your account and exactly the rights your role has in the dashboard.

How does the server work?

According to the provider's blog post, the server covers hundreds of operations, including organizations, SSO connections, directory sync, AuthKit users and sessions, roles, audit logs, webhooks, and branding. Instead of offering a separate tool for every endpoint, there are only four: whoami, list_operations, query, and mutate. The agent first looks up the matching operation and then runs it. That keeps the language model's context window lean because hundreds of tool descriptions do not have to be loaded.

What is it particularly useful for?

The greatest value lies in support and onboarding. As an example the provider names a support case: the agent finds a SAML connection whose metadata address returns a 404 error, checks the failed sign-ins, and creates an Admin Portal link for the customer's IT department. Further ideas include styling the sign-in page from a screenshot, finding incomplete SSO setups, or configuring audit log streams. Compared with the WorkOS command line, which runs locally next to the code, the MCP server needs no installation and works on any device, for example for bots or agents handling tickets.

Setup

The documentation describes setup for numerous clients. In Claude Code, claude mcp add --transport http workos https://mcp.workos.com/mcp is enough, after which you confirm the sign-in in the browser; /mcp shows the status. In Cursor you put the address into mcp.json, and in Codex you use codex mcp add workos --url https://mcp.workos.com/mcp followed by codex mcp login workos. VS Code, Zed, Goose, OpenCode, Factory, Antigravity, and Claude Desktop are also named. For ChatGPT a suitable plan is required for custom connectors.

Permissions and security

The agent inherits exactly your dashboard rights and cannot do more. By default it works in the sandbox environment, and in production only on explicit instruction. Secrets such as API keys and client secrets are removed from responses before they reach the agent's context. According to the provider, irreversible deletions require explicit confirmation after a description of the consequences. Not possible are, among other things, minting or rotating keys, impersonating users, billing, and deleting the team. Team admins can control access in the settings with three switches: MCP overall, production access, and write access.

Costs

The server requires a WorkOS account. According to the pricing page there is a free entry tier for the AuthKit user management, usage-based prices for products such as SSO and directory sync, and individual enterprise contracts. Whether a specific tier is needed for MCP access is not stated in the documentation; details are on WorkOS's official pricing page.

Who is the WorkOS MCP Server for?

It is worthwhile for teams that already use WorkOS and would rather handle recurring tasks such as customer onboarding, SSO troubleshooting, and user management in conversation with an assistant. Anyone not using WorkOS gains nothing from it, since the server is not a standalone sign-in solution. It is advisable to enable only read access and the sandbox at first and to grant write rights after initial tests.

A WorkOS account with a dashboard role, an MCP client that supports remote servers (Streamable HTTP), and MCP access enabled by the team admin.

With the WorkOS MCP Server, an AI assistant manages your WorkOS workspace. This guide leads from setup to the first request.

Step 1: Check the prerequisites

You need a WorkOS account with a dashboard role and an MCP client that supports remote servers. Nothing has to be installed locally because the server is hosted by WorkOS. A team admin must have enabled MCP access in the team authentication settings; according to the documentation it is on by default.

Step 2: Register the server in Claude Code

The address is https://mcp.workos.com/mcp, and the transport is Streamable HTTP. In Claude Code the command claude mcp add --transport http workos https://mcp.workos.com/mcp is enough. With /mcp you check the status or sign in again.

claude mcp add --transport http workos https://mcp.workos.com/mcp

Step 3: Other clients

In Cursor you add an entry workos under mcpServers in ~/.cursor/mcp.json or .cursor/mcp.json with the address as url and then click Login in the settings. In Codex you run codex mcp add workos --url https://mcp.workos.com/mcp and then codex mcp login workos; restart the session after consenting. In VS Code you use .vscode/mcp.json with the type http.

codex mcp add workos --url https://mcp.workos.com/mcp
codex mcp login workos

Consent

On the first connection a consent screen from WorkOS opens. Sign in and grant access. The agent then acts with your account and exactly the rights of your dashboard role.

Step 4: First requests

Start read-only, for example with "Which organizations exist in my sandbox?". According to the provider the server offers four tools: whoami, list_operations, query, and mutate. You do not have to name them; the agent finds the matching operation itself.

Sandbox and production

By default the agent works in the sandbox. It reaches production only on explicit instruction and only if the team admin has allowed production access. Test changes in the sandbox first.

Limit the rights

Team admins can switch MCP overall, production access, and write access on or off separately in the settings. If you want to read only at first, switch write access off. According to the provider, deletions require explicit confirmation.

OAuth through WorkOS Connect: on first connection a consent screen appears where you sign in and grant access. The agent then acts as your account.

Access to organizations, connections, users, roles, audit logs, and branding of the WorkOS team within the dashboard rights of the signed-in person. Team admins can switch off production access and write access separately.

The server runs hosted by WorkOS. According to the provider, secrets such as API keys are removed from responses; retrieved user and configuration data does enter the AI client context and therefore reaches the model provider.

Unwanted changes to sign-in and SSO settings or deletions, especially with automatically approved calls and enabled production access, and passing personal user data to the model provider.