What Is Clerk MCP and Is It Safe to Connect?

Clerk MCP lets an AI agent manage users, sessions and organizations in your auth system, so connect it carefully. Clerk's official page lists six tools, and two of them create and delete users. Point it at a test instance with a test secret key, keep a human approving every write call, and only then consider a live application.

What is Clerk MCP and what does it expose?

Clerk's official page describes the server as a way to manage Clerk users, sessions, and organizations for auth flows from any MCP client. In practice that means Claude Code, Cursor, Windsurf or another MCP-compatible agent can call a small set of tools against your Clerk application instead of you clicking through a dashboard.

The same page lists six tools. Four deal with users: list_users (with an optional limit), get_user (needs a user_id), create_user (needs an email_address, with an optional password) and delete_user (needs a user_id). The other two, list_organizations and list_sessions, list the organisations in the app and the active sessions.

So the surface is narrow: reading identity data, creating accounts and deleting accounts. It does not sprawl across hundreds of operations, which makes it easier to reason about than many broader servers. You can browse the full entry at Clerk in the directory.

What is Clerk and where does an MCP server fit?

Clerk is an authentication and user-management service. Your application sends sign-ins, sessions and organisation membership through it, and it keeps the user records. An MCP server is a small bridge that exposes some of those capabilities as tools an agent can call, following the pattern described in What Is MCP (Model Context Protocol)? Explained.

The MCP server does not replace Clerk or sit in your sign-in path. Your users never touch it. It is an operator-side tool: you, or an agent working for you, use it to inspect and change the data Clerk already holds. That is useful when you are debugging an auth flow, checking whether a test account exists, or seeding a few users while building.

The official page shows two ways to run it. One is a local command that starts the @clerk/agent-toolkit package with the --mcp flag through npx. The other is a hosted HTTP transport added with claude mcp add --transport http clerk. The trade-offs between those styles are covered in Local vs Remote MCP Servers: What Changes.

What access do you grant when you connect it?

In the local setup shown on Clerk's official page, the server reads a CLERK_SECRET_KEY environment variable, and the example value starts with sk_test_. The agent acts with whatever that key allows, so the key you choose defines the blast radius far more than the tool list does.

A typical Claude Code entry in ~/.claude.json looks like this, and Cursor uses the same block in .cursor/mcp.json:

{
  "mcpServers": {
    "clerk": {
      "command": "npx",
      "args": ["-y", "@clerk/agent-toolkit", "--mcp"],
      "env": { "CLERK_SECRET_KEY": "sk_test_..." }
    }
  }
}

Practically, you are granting three capabilities: reading user, organisation and session data, creating users, and deleting users. Reading exposes personal information such as email addresses to the model's context. The two write tools change real records. For a deeper look at how servers frame this, see MCP Server Permissions and Scopes Explained.

Is Clerk MCP safe to connect to a real instance?

It is safe enough on a test instance and risky on a live one without safeguards. The tools themselves are plain, but delete_user is destructive and create_user can add accounts with a password the agent chooses. A misread instruction, or a prompt injected through some text the agent reads, could trigger either call.

Work through these checks before connecting:

• Use the test key, the sk_test_ style shown on the official page, never a live key, while you evaluate the server.
• Keep the key in an environment variable or secret store, not in a committed config file.
• Set your client to ask for approval on every tool call, so each create or delete needs a human yes.
• Start by calling only the read tools, list_users, get_user, list_organizations and list_sessions, and watch what comes back.
• Review the package source yourself, following How to Audit an MCP Server Before Install.

If you later move to a live application, prefer a dedicated environment and a plan for restoring deleted users, because the delete tool takes only a user ID.

What Clerk MCP does not do

The six listed tools are the whole surface on the official page. There is no tool for editing an existing user, for updating an organisation, or for revoking a session; the session tool only lists active sessions. If your task needs those operations, the agent has no sanctioned way to perform them through this server.

It also does not sign anyone in, issue tokens for your end users, or sit between your app and Clerk at runtime. It is a management helper for you, not a component of your product's login flow. Nothing about adding it changes how your customers authenticate.

Finally, connecting it is not a security review of your identity setup. It will not tell you whether your sessions are configured sensibly or whether an account looks suspicious. It reports and changes records on request. Treat any judgement about those records as your own, and use the agent as an assistant that fetches facts quickly.

How does Clerk MCP compare with other identity servers in the directory?

The closest listed alternative is Auth0. Auth0's official page describes managing tenants, users, roles and applications from agents, and it also lists six tools: list_users, get_user, list_applications, list_connections, list_logs and list_roles. Notably, all six are read-style listings, with no create or delete tool in that set.

That difference matters for the safety question. Clerk's server includes create and delete for users, while Auth0's listed tools only read. If you want an agent that can inspect and diagnose but not alter accounts, the read-only shape is lower risk. If you actually need to seed or remove test users, Clerk's tools fit that job.

• Clerk — Listed tools: Six — Can create or delete users: Yes, both — Published audit: None published
• Auth0 — Listed tools: Six — Can create or delete users: No, read-style tools — Published audit: CheckMCP: 87/100, grade B

As of October 20, 2026, the CheckMCP audit of the Auth0 repository reports 113 stars, an MIT licence, 8 open issues and a last commit 10 days earlier. It scores licence, adoption, maintenance and documentation, and is a signal about the repository, not a guarantee about your tenant.

Next step: the Clerk listing

When you are ready to try it, open the Clerk listing and check the install options. The CLI route is mcpizy install clerk, which the page describes as taking about 1 minute. You can also add the hosted transport directly with claude mcp add --transport http clerk followed by the endpoint shown on the listing.

Start in a throwaway test instance. Run list_users with a small limit, confirm the data matches what you see in Clerk's own dashboard, and only then try a create followed by a delete on a dummy account. That sequence shows you exactly how your client prompts for approval before anything changes.

If your wider workflow also touches billing or alerts, pair what you learn here with the other guides, such as How to Use Stripe MCP with Claude Code, and apply the same habit: test credentials first, approvals on, secrets out of version control.