Clerk's MCP server now manages your apps
- Category
- Company
- Published
Sign in once and your agent can read and change your Clerk apps through the Model Context Protocol, with the permissions you approve.
Your agent can already pull Clerk code from Clerk's Model Context Protocol (MCP) server. Tell it to create a test user and it stops. Without the Clerk command-line interface (CLI) set up, it sends you to the Clerk Dashboard and waits.
Today that handoff goes away, because Clerk's MCP server now connects to your Clerk account. Sign in once from a client that supports MCP sign-in, and approve what the agent may do. It then reads and changes your apps from the same session.
Sign in once
When your client connects to the server, it prompts you to sign in to Clerk. You need a Clerk account for this part. Not every MCP client completes this step yet.
A consent screen lists what the agent is asking for, such as reading your applications or managing users. You approve the whole set or none of it. There's no partial consent.
Each action needs a matching permission. Listing apps needs read access, and creating one needs manage access. If you need a permission you didn't grant, sign out and connect again to approve it.
The SDK snippet tools you use today are still there. They now need the same sign-in.
Manage apps and instances
At launch the agent can see your workspace and the apps in it. It can read an app or create a new one. It can read an instance's settings, with sensitive values redacted, and change those settings.
Show the authentication settings for my development instance.
The agent can also list an instance's users with filters and create a user.
Create a test user in my development instance with the email
ada@example.com.
It lists an app's domains with the Domain Name System (DNS) records each one needs. It checks DNS, certificate, and email verification status. After you add a record, it asks Clerk to re-check.
List the domains on my app and tell me which DNS records are still missing.
It doesn't cover everything the Clerk Dashboard does yet.
Take an app to production
Your agent can now walk you through the same production setup as the Clerk Dashboard and clerk deploy. Going live has three parts: a production instance, DNS records, and production credentials for your OAuth providers.
It starts by listing the OAuth providers you enabled in development and flags the ones missing production credentials. Then it creates a production instance on the domain you give it, copying your development settings. You get back the DNS records to add and the next steps.
Take this app to production on example.com and tell me what's left.
Creating a production instance can't be undone, so the tool refuses to run without an explicit confirmation flag. A well-behaved agent checks with you before it sets it.
Add the records, then have the agent ask Clerk to re-check DNS. Add your production OAuth credentials in the Clerk Dashboard, so the secrets stay out of your chat.
Permissions stay narrow
Sign-in doesn't hand the agent one key to everything. Each call that reads or changes your apps gets a token with only that tool's permissions, and it expires within 5 minutes. A tool that lists users can't touch domains, even if you granted both. The agent also can't do more than your workspace Role allows.
No secret key goes into your MCP client config, and no tool returns one. Keys stay where they are today, in the Clerk Dashboard and clerk env pull.
Instance setting changes and user creation accept a dry run. Ask the agent to show a change before it applies it.
Get started
Add https://mcp.clerk.com/mcp to your AI client as a remote MCP server, then sign in with your Clerk account when the client connects. The agent takes it from there.
See the Clerk MCP server docs for setup steps for each client and the full list of tools.
Tell us what the agent should do next in the Clerk Discord.
Ready to get started?
Start building