Loading ToolBench
MCP server for Clerk — query organizations, members, users, roles, and metadata via AI assistants
The Clerk MCP server demonstrates solid fundamentals: 14 well-named tools with explicit input schemas, consistent use of Zod validation, and tool annotations (readOnlyHint/destructiveHint). Descriptions are present and adequate (150-200 chars average). However, there are notable gaps: output schemas are not formally documented in the source code visible here, some parameter descriptions could be more detailed about constraints and error recovery, and the server lacks comprehensive error handling with recovery guidance. The implementation follows modern MCP patterns but misses advanced composition and LLM-optimization details. Based on visible code (server/ tools, app structure), this is a well-structured but not exceptional implementation.
Invite a user to a Clerk organization by email. Sends an invitation email and creates a pending invitation record. Requires the inviter's user ID.
Create a new Clerk organization. Requires a name; optionally set slug, max memberships, a creating user, and initial metadata.
Delete a Clerk organization by ID. This is irreversible — all memberships, invitations, and associated data will be removed.
Get detailed information about a single Clerk organization by ID or slug. Returns name, slug, metadata (public + private), member limits, and timestamps.
Get detailed information about a single Clerk user by their user ID. Returns full profile, email addresses, phone numbers, metadata, external accounts, and timestamps.
Output schemas not formally documented. Tool descriptions state what the response will contain (e.g. 'Returns org ID, name, slug, metadata, and timestamps') but the actual JSON schema structure is not provided in visible code. LLMs cannot reliably extract nested fields or plan downstream calls without explicit output schemas.
Error handling lacks recovery guidance. The visible handler code shows try-catch with clerkCall() but no recovery hints are returned to the LLM (e.g., 'Organization not found. Try clerk_list_organizations() to see available orgs.'). Agents cannot self-correct when a tool fails.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
List invitations for a Clerk organization. Filter by status (pending, accepted, revoked). Returns invitee email, role, status, and timestamps.
List members of a Clerk organization. Returns each member's user ID, role, public user data (name, email, avatar), membership metadata, and timestamps. Supports filtering by role, email, query string, and pagination.
List all Clerk organizations. Supports filtering by name/slug/ID, pagination, and optional member counts. Returns org ID, name, slug, metadata, and timestamps.
List Clerk users across the entire instance. Supports filtering by email, phone, username, user IDs, and more. Returns user profile data, metadata, and timestamps.
Remove a member from a Clerk organization. The user will lose access to the organization but their Clerk user account is not deleted.
Update a member's public metadata within a Clerk organization. Metadata is merged with existing values. Set a key to null to remove it.
Change a member's role within a Clerk organization. Common roles: "org:admin", "org:member", or any custom role defined in your Clerk dashboard.
Update an organization's public and/or private metadata. Metadata is merged (deep merge) with existing values. Set a key to null to remove it. Returns the updated organization.
Update a user's metadata (public, private, and/or unsafe). Metadata is merged with existing values. Set a key to null to remove it. Returns the updated user.
Some parameter descriptions lack format constraints and edge-case guidance. For example, 'role' parameters in clerk_update_member_role and clerk_create_invitation accept strings but do not specify valid values ("org:admin", "org:member", custom roles). LLMs may hallucinate invalid role names without an enum or explicit list.
Destructive operations (clerk_delete_organization, clerk_remove_member) lack confirmation or dry-run support. No confirmation_request pattern is implemented. Agents may invoke these tools without explicit user approval, risking data loss.
Response field naming consistency not verifiable from visible code. Tool descriptions reference fields like 'org ID', 'name', 'slug', but the actual JSON keys returned are not shown. If clerk_list_organizations returns 'org_id' but clerk_get_organization returns 'id', the LLM cannot chain them reliably.
Result limiting not documented. clerk_list_organizations has a 'limit' param (default 20, max 100) and clerk_list_users has a 'limit' param (default 20, max 200), but descriptions do not warn about context window impact or recommend pagination. Large result sets could blow token budgets.