Clerk MCP Server: Setup, Tools & Real Limits
Clerk’s official MCP server gives coding agents current implementation patterns, but it does not manage your Clerk instance or user data.
Clerk MCP is Clerk’s first-party, hosted server for feeding current SDK snippets and implementation patterns to AI coding assistants. Connect it when an agent is writing Clerk integration code; do not expect it to list users, alter organizations, inspect sessions, or administer your tenant. Its narrow, read-only scope is both its best safety feature and its biggest limitation.
Table of contents
- What Clerk MCP actually is
- What exists today
- Setup
- Tools you get
- Permissions and blast radius
- Real limits
- When not to use it
What Clerk MCP actually is
Clerk MCP is a documentation aid for coding agents, not an agent-operated Clerk control plane. Once connected, an assistant can discover Clerk’s available snippet catalog and retrieve code patterns for authentication, Organizations, waitlists, custom flows, and server-side integration.
That distinction matters. “Show me a Next.js route-protection pattern” fits the server; “revoke this user’s session” does not. Clerk describes SDK snippets and implementation guides, and its official MCP guide documents only two retrieval tools.
MCP supplies the standard connection between the model-facing client and that remote service. It does not make the model authoritative or guarantee that retrieved code matches your installed SDK version or application policy. If you are comparing broader integrations, browse the best MCP servers and check each server’s actual capabilities, not its marketing category.
Our view: this tight scope is the right design for a vendor documentation server. It reduces secret handling and prevents an ambiguous request from becoming a destructive identity operation. The trade-off is that “Clerk MCP” sounds more operational than the product is.
What exists today
The option to choose today is Clerk’s first-party hosted server at https://mcp.clerk.com/mcp, currently labeled beta. It uses Streamable HTTP, and Clerk explicitly says the API can change before general availability and that SSE is not supported.
There is also an older @clerk/clerk-mcp npm listing that can expose Clerk API operations and asks for a Clerk Secret Key. Its own npm page warns that the project is in active development and subject to rapid changes. That package is not the same experience as the hosted snippet server in Clerk’s current setup guide.
| Option | Maintainer/status | Data access | Our recommendation |
|---|---|---|---|
Hosted mcp.clerk.com server | First-party, public beta | Published snippets and bundles | Use for day-to-day coding assistance |
@clerk/clerk-mcp package | Clerk-scoped package, experimental warning | Potential Backend API access via a Secret Key | Avoid for production agent access unless you audit and deliberately need its API surface |
| Custom MCP server using Clerk auth | You maintain it | Whatever tools you implement | Use when your own product needs authenticated MCP tools |
Clerk separately documents how to build an MCP server with Clerk OAuth. That guide is for protecting your server and defining your own tools; it is not a hidden admin mode for the hosted Clerk MCP service. We classify the hosted server among official integrations, while treating custom and package-based options as separate deployments requiring risk reviews.
Setup
Setup requires an MCP client that supports remote Streamable HTTP; the hosted server requires no Clerk Secret Key, OAuth grant, or scopes. The simplest supported route is Clerk’s CLI, while direct JSON is appropriate when your client accepts URL-based MCP entries.
- Install the Clerk CLI using an option in the official CLI guide, then run
clerk mcp install. The command detects supported clients and writes a user-global registration. - Restart or reload the client so it rereads its MCP configuration.
- Ask the client to list the Clerk tools, or run
clerk doctorto check whether the endpoint is reachable. - If auto-detection is undesirable, add the remote server manually. For Cursor, Clerk documents this exact shape:
{
"mcpServers": {
"clerk": {
"url": "https://mcp.clerk.com/mcp"
}
}
}
Do not paste CLERK_SECRET_KEY into that entry: the hosted snippet service does not need it. For Claude Desktop and clients without native remote HTTP support, Clerk documents an mcp-remote bridge; client syntax differs, so use the vendor’s per-client instructions or generate a starting point with MCP Directory’s config generator.
The common failure is transport mismatch. An SSE-only client will not connect because this endpoint supports Streamable HTTP only. An “internal server error” can also be a network or transport problem; Clerk recommends disconnecting and reconnecting after confirming client support in its connection FAQ.
Tools you get
You get exactly two documented tools, both aimed at discovering or retrieving implementation material. Neither one reads your application’s users, organizations, sessions, billing state, or Dashboard configuration.
| Tool name | What it does | What it does not do |
|---|---|---|
list_clerk_sdk_snippets | Lists available snippets and bundles | Query a Clerk instance |
clerk_sdk_snippet | Retrieves SDK code patterns for a requested feature | Execute the code or mutate tenant data |
Documented bundles include b2b-saas, waitlist, auth-basics, custom-flows, organizations, and server-side. The authoritative list and names live in Clerk’s available-tools section; check discovery rather than hard-coding assumptions, because beta interfaces can move.
I would ask the agent to retrieve one focused pattern, then review the output against the project’s installed Clerk SDK. I would avoid requesting a comprehensive bundle unless the task truly spans several features: large, generic examples consume context and make it easier to overlook framework-version differences or paste irrelevant code.
Permissions and blast radius
The hosted Clerk MCP server has no documented access to your Clerk tenant, so start with it as-is and give it no secrets. There is no integration account to create for this public snippet service; the dedicated-account rule becomes relevant only if you choose an API-capable package or build custom tools.
That narrow permission model keeps the direct blast radius low. The indirect risk remains real: an agent can write authentication middleware, authorization checks, or organization-role logic incorrectly. Require code review and tests before merging, especially around route protection and server/client boundaries. MCP tool output is reference material, not a security decision.
For any custom administrative server, use a dedicated development instance or narrowly authorized integration identity, expose read-only tools first, require confirmation for writes, and keep deletion, session revocation, bans, invitations, and role changes out of the first release. Clerk’s Backend API reference shows why: those operations can delete users, revoke sessions, send invitation emails, and change organization memberships. A careless write can lock out a real customer or disclose access across a tenant boundary.
Never give a general-purpose desktop agent a production Secret Key merely to obtain coding examples. That exchanges the hosted server’s safety advantage for an unnecessary administrative blast radius.
Real limits
The decisive limit is functional: Clerk MCP returns curated code guidance, not live tenant facts or arbitrary Clerk documentation. It cannot inspect why a particular user failed sign-in, read application or email logs, report usage, change Dashboard settings, or call Backend API endpoints.
Result size still competes with the model’s context window. A broad bundle may be valid yet crowd out your repository code, constraints, and earlier decisions; retrieve the smallest relevant snippet and summarize before fetching another. MCP itself does not guarantee that a client will preserve every returned token or choose the right pattern.
Clerk does not publish a separate request quota for the hosted snippet endpoint in its MCP guide. Do not substitute Backend API numbers as though they govern this service. If you build an API-backed alternative, however, Clerk’s rate-limit documentation applies: production Backend API traffic is generally limited to 1,000 requests per 10 seconds, development to 100 per 10 seconds, with tighter endpoint-specific caps and 429 responses carrying Retry-After.
There are also product boundaries no MCP wrapper removes. Clerk’s CLI documentation says analytics, usage metrics, application and email logs, workspace membership, subscription billing, Account Portal branding, and Clerk Protect settings remain Dashboard-only. A wrapper cannot safely promise an API operation that Clerk does not expose.
When not to use it
Do not use Clerk MCP when a normal document lookup, a deterministic API script, or Clerk’s own CLI directly matches the job. Choose the least capable interface that completes the task; it is easier to test and easier to audit.
Use Clerk’s docs or installed agent skills for a one-off conceptual question. Use clerk init for supported project scaffolding, clerk api for an explicit authenticated Backend API call, and a short SDK script for repeatable migrations or reports. The Clerk CLI reference also identifies Dashboard-only work, saving you from trying to automate an unavailable endpoint.
Use Clerk MCP when the agent is already editing code and needs current, vendor-curated examples in its tool loop. Avoid it for runtime authentication, production administration, bulk user changes, incident response, or jobs requiring stable machine-readable output. My choice would be the hosted server for coding assistance and a reviewed script for operations—the extra implementation work buys determinism, logging, retries, and a clear permission boundary.