Clerk MCP integration for AI agents.
Connect AI agents to Clerk through 11 structured actions, including count users, create user, ban user, and lock user. Review authentication, inputs, workflo…
- ACTION CONTRACTS
- 11
- AUTHENTICATION
- API key
- SOURCE STATUS
- Provider-backed
CATALOG SOURCE REVIEWED AUGUST 23, 2026 / ACTION NAMES AND SCHEMAS DERIVED FROM WORKING MACHINES PROVIDER SOURCE
CAPABILITY PROFILE
What the Clerk integration exposes
The Clerk Agent App exposes 11 provider-backed actions for security and developer tools work. Its current contract lets an authorized agent count clerk users with optional filters, create a clerk user, and ban a clerk user. These operations are called through Working Machines as typed capabilities rather than through browser navigation or copied UI steps.
A connection uses API key. Before execution, the agent can inspect the selected action, its required fields, declared scopes, and expected output contract. Provider credentials remain inside the Working Machines runtime; the calling agent receives the capability and its structured result, not the underlying secret.
For reliable operation, start with the narrowest action that satisfies the task, resolve stable provider identifiers before changing state, and validate the returned object or status after execution. Availability still depends on the connected Clerk account, granted provider permissions, workspace policy, region, plan, and upstream API behavior.
VERIFIED ACTION SAMPLE
Real Clerk capabilities.
Showing 11 of 11 actions. Risk labels are conservative signals based on operation names, not substitutes for provider documentation or runtime policy.
count_usersREADCount Clerk users with optional filters.
INPUTS: email_address / phone_number / username / user_id / external_id
create_userWRITECreate a Clerk user.
INPUTS: email_address / phone_number / web3_wallet / external_id / first_name
ban_userHIGH IMPACTBan a Clerk user.
INPUTS: user_id
lock_userREVIEWLock a Clerk user.
INPUTS: user_id
delete_userHIGH IMPACTDelete a Clerk user.
INPUTS: user_id
get_userREADRetrieve a Clerk user by ID.
INPUTS: user_id
list_usersREADList Clerk users with optional filtering and pagination.
INPUTS: email_address / phone_number / username / user_id / external_id
unban_userREVIEWUnban a Clerk user.
INPUTS: user_id
unlock_userREVIEWUnlock a Clerk user.
INPUTS: user_id
update_userWRITEUpdate a Clerk user.
INPUTS: user_id / first_name / last_name / primary_email_address_id / primary_phone_number_id
update_user_metadataWRITEDeep merge metadata for a Clerk user.
INPUTS: user_id / public_metadata / private_metadata / unsafe_metadata
INPUT CONTRACTS
Know what the action needs before it runs.
count_users
email_addressOPTIONAL- A list of string values used by Clerk filters.
phone_numberOPTIONAL- A list of string values used by Clerk filters.
usernameOPTIONAL- A list of string values used by Clerk filters.
user_idOPTIONAL- A list of string values used by Clerk filters.
external_idOPTIONAL- A list of string values used by Clerk filters.
create_user
email_addressOPTIONAL- Email addresses to add to the new user.
phone_numberOPTIONAL- Phone numbers to add to the new user.
web3_walletOPTIONAL- Web3 wallet addresses to add to the new user.
external_idOPTIONAL- An external ID for the user.
first_nameOPTIONAL- The user's first name.
ban_user
user_idREQUIRED- The Clerk user ID.
lock_user
user_idREQUIRED- The Clerk user ID.
PROVIDER-SPECIFIC WORKFLOWS
Jobs this Agent App can support
Inspect Count Users
Count Clerk users with optional filters. Use this as a bounded discovery step, retain the returned identifier, and avoid expanding the read beyond the task's stated scope.
count_usersControl Create User
Create a Clerk user. Resolve the target first, present material changes for confirmation, and make retries idempotent where the provider supports it.
create_userVerify with Get User
Retrieve a Clerk user by ID. Compare the returned provider state with the intended outcome and preserve stable IDs or canonical links in the run record.
get_userSAFETY BOUNDARY
Operate Clerk with explicit limits
- Authorize Clerk with API key and grant only the provider access required by the selected actions.
- 5 actions are change-capable by name. Confirm the target identity and material parameters before allowing a write.
- Treat `ban_user` and `delete_user` as high-impact operations and require an explicit approval boundary.
- No provider scope string is declared on the sampled actions. Verify the connected account's actual permissions in Clerk rather than assuming unrestricted access.
- After a call, inspect the structured result and execution record before reporting that the Clerk task completed successfully.
CONNECTION MODEL
API key
Clerk secret key used with the Authorization Bearer header. Create or reveal it in the Clerk Dashboard API keys page: https://dashboard.clerk.com/last-active?path=api-keys
Working Machines stores provider credentials behind the execution boundary. An agent can use an authorized connection identity, but catalog discovery alone does not reveal OAuth tokens, API keys, or provider secrets.
- READ SIGNALS
- 3
- WRITE SIGNALS
- 3
- HIGH IMPACT
- 2
- REVIEW SIGNALS
- 3
EVIDENCE AND AVAILABILITY
Provider reference
Action names, input fields, authentication types, and counts on this page are generated from the Working Machines provider catalog. Provider behavior, quotas, object semantics, account eligibility, and regional availability remain governed by Clerk.