Install command
Provided
Configure and manage Stytch authentication services and workspace settings
Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.
Decision playbook
Signals are comparatively strong, but you should still validate source, privacy posture, and package provenance for your environment.
0
96
—
No baseline selected
No major trust-signal divergence detected in the current selection.
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Source provenance statusRequired
Marked as first-party.
Metadata reviewed
Registry metadata indicates a reviewed listing.
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Trust level risk gateRequired
Trust level does not block evaluation.
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Package verification flag
Package marked verified.
Checksum metadata
SHA-256 hash is present.
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
Baseline comparison available
No baseline peer selected yet.
Diverging trust signals identified
No major trust-signal divergence found.
Setup at a glance
Copy-ready — paste the snippet to get started.
Install command
Provided
Config snippet
Provided
Copy snippet
Provided
Prerequisites
10 to clear
Platforms
2 listed
Difficulty
11/100
Adoption plan
Current risk score 0/100. Use staged verification before broader rollout.
Validate source and review signals before any execution.
Confirm source provenanceRequired
Source URL/provenance metadata is present.
Confirm metadata review state
Listing has review metadata.
Verify install payload
Install/config payload exists and can be inspected.
Confirm safety, privacy, and package integrity signals.
Review safety notesRequired
Safety notes are present.
Review privacy notesRequired
Privacy notes are present.
Verify package integrity metadata
Package verification/checksum metadata is available.
Adopt in controlled steps based on the selected plan.
Run in isolated sandbox firstRequired
Use a constrained sandbox and observe behavior across multiple tasks.
Roll out graduallyRequired
Roll out to a small cohort before wider usage.
Set monitoring and fallback
Define rollback path and monitor errors after adoption.
Evidence readiness
Required evidence gates are covered (6/6 signals complete).
Source repository/provenance is listed.
Required in this preset
Review metadata is present.
Required in this preset
Safety notes are present.
Required in this preset
Privacy notes are present.
Optional in this preset
Package integrity metadata is present.
Optional in this preset
Install payload is available.
Required in this preset
Required evidence gates are covered for this preset.
Decision timeline
6/6 steps complete with no blocking gaps for this preset.
triage
Source/provenance metadata is available.
triage
Review metadata is available.
verify
Safety notes are available.
verify
Privacy notes are available.
verify
Package integrity metadata is available.
rollout
Install payload is available.
No required blockers for this timeline preset.
Prerequisite readiness
10 prerequisites to line up before setup. Have accounts and credentials ready first.
Safety & privacy surface
1 safety and 1 privacy notes across 2 risk areas. Review closely: credentials & tokens, permissions & scopes.
{
"stytch": {
"url": "http://mcp.stytch.dev/mcp",
"transport": "http"
}
}Manage Stytch authentication configurations and workspace settings for identity management. Configure authentication methods (magic links, OAuth, passwords, biometrics), manage redirect URLs and callbacks, customize email templates and branding, update security settings (MFA, sessions, policies), monitor authentication events and metrics, manage user sessions, configure B2B authentication (SSO, organizations), and set up fraud detection—all through natural language commands. Supports Basic authentication, test and live environments, and comprehensive identity management.
{
"stytch": {
"url": "http://mcp.stytch.dev/mcp",
"transport": "http"
}
}
Common usage pattern for this MCP server
Ask Claude: "Add new redirect URL for production"
Common usage pattern for this MCP server
Ask Claude: "Update password reset email template"
Common usage pattern for this MCP server
Ask Claude: "Configure MFA settings"
Common usage pattern for this MCP server
Ask Claude: "Show authentication metrics for this week"
Authenticate a user using Stytch magic link with session duration
// Authenticate user with Stytch
const session = await stytch.magicLinks.authenticate({
token: "magic-link-token",
session_duration_minutes: 60,
});
Stytch enforces rate limits per endpoint and per user/email/phone number separately. Test environment example: 60 SMS OTP codes per hour per project. Check error response for Retry-After header to know when to retry. Implement exponential backoff for retries (wait time increases with each retry). Review Stytch rate limits documentation for specific endpoint limits. Check Event logs in Stytch Dashboard to investigate context around 429 errors. Contact Stytch support (support@stytch.com) for rate limit increases or if receiving unexpected 429 errors during legitimate user flows. Monitor for suspicious user activity that may trigger per-user rate limits.
Redirect URLs must be configured in Stytch Dashboard under redirect_urls section. Production requires https:// scheme (never http:// except for localhost loopback). Development can use http://localhost for local testing. Verify URL exact match (case-sensitive, must match exactly). Check no duplicate redirect URLs configured. Ensure URL is added to correct project environment (test vs live). For OAuth flows, URL must match one of the configured redirect URLs exactly. Common error: no_match_for_provided_oauth_url indicates URL not in Dashboard configuration.
Ensure client has valid redirect_urls configured in Stytch Dashboard. Public clients require proper scheme: https:// for production, http://localhost only for localhost loopback. Localhost restrictions apply to certain client types. Verify client ID matches project (check project_id in client configuration). Check redirect URL types match intended use (LOGIN, SIGNUP, INVITE, DISCOVERY for B2B). Ensure default redirect URLs are set if not providing URL in request. Review client configuration in Dashboard for any restrictions.
Verify API keys match environment: test environment credentials for test API calls, live credentials for production. Check project_id and secret from Stytch Dashboard (API Keys section). Ensure user has project access permissions in Dashboard. Re-generate API keys if compromised. Review project security settings in Dashboard. Verify Basic authentication format: Basic <base64-encoded-project_id:secret>. Check that credentials are for correct environment (multiple test environments available, single live environment). Ensure API keys are not revoked or expired.
Verify API keys (Project ID and Secret) are valid and not expired. Check API keys match the correct environment (test vs live). Ensure API key format is correct. For webhook verification, verify webhook signing secret matches.
Implement exponential backoff retry logic with jitter. Use Stytch API rate limit headers to monitor usage. Reduce concurrent requests. Cache frequently accessed user data. Stytch allows 100 requests per second per project.
Verify API keys have access to the user or session. Check project permissions and organization membership. Ensure API keys have required permissions for target operations.
Check network connectivity and firewall settings. Verify Stytch API endpoints are accessible. Increase request timeout values. Implement connection pooling and retry mechanisms with exponential backoff.
Stytch MCP Server for Claude side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
2 trust signals differ across this comparison (Package trust, Submitter).
| Field | Configure and manage Stytch authentication services and workspace settings Open dossier | Connect Claude to Auth0's official local MCP server for tenant administration, application setup, Actions, logs, forms, and scoped Management API workflows. Open dossier | Official AWS Labs MCP server for AWS Identity and Access Management that lets AI assistants inspect and manage IAM users, roles, groups, policies, and access keys, with policy simulation and an opt-in read-only mode. Open dossier | Manage your Descope identity project from Claude — search users, configure auth flows, inspect audit logs, manage tenants, and search Descope documentation — with the official Descope remote MCP server hosted at mcp.descope.com. Open dossier |
|---|---|---|---|---|
| Next steps | ||||
| Trust | ||||
| Review status | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed |
| Package trustDiffers | Package verified | Package not verified | Package not verified | Package not verified |
| Source provenance | Source-backed | Source-backed | Source-backed | Source-backed |
| SubmitterDiffers | — | MkDev11 | jaso0n0818 | — |
| Install risk | Low risk | Review first | Review first | Review first |
| Notes | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ |
| Brand | — | — | ||
| Category | mcp | mcp | mcp | mcp |
| Source | first-party | source-backed | source-backed | source-backed |
| Author | Stytch | Auth0 | AWS Labs | Descope |
| Added | 2025-09-18 | 2026-06-05 | 2026-06-21 | 2026-06-18 |
| Platforms | Claude CodeClaude Desktop | Claude CodeClaude Desktop | Claude CodeClaude Desktop | Claude CodeClaude Desktop |
| Source repo | — | — | — | — |
| Safety notes | ✓Restrict Stytch workspace and admin permissions because auth configuration changes can affect sign-in and account security. | ✓Auth0 documents the server as beta software. Treat command behavior, available tools, requested scopes, and client setup flows as subject to change until Auth0 publishes a stable release. Start with `--read-only` or a narrow `--tools` pattern such as `auth0_list_*,auth0_get_*`. Enable create, update, deploy, or publish tools only for a scoped task and an approved tenant. The server can expose tools for applications, APIs, client grants, Actions, logs, and forms. Some of those tools can change callback URLs, token settings, Actions code, branding, and other live authentication behavior. Review every mutating tool call before approving it. A mistaken tenant change can break sign-in, weaken security settings, deploy incorrect Actions, expose callback URLs, or affect production users. Keep token lifetime and Management API scopes as small as possible when using the client-credentials setup path. Revoke or rotate credentials that were created for temporary MCP work. Use `npx @auth0/auth0-mcp-server logout` when finished or when switching tenants so local authentication state is removed from the system keychain. | ✓Run with the `--readonly` flag (shown above) to block all mutating operations. Without it the server can create and delete IAM users, roles, groups, policies, and access keys — high-impact identity changes — so enable write access only deliberately and with scoped permissions. IAM controls account-wide access; a misused write operation can grant or revoke permissions broadly. Prefer non-production accounts while evaluating, and use policy simulation to test changes before applying them. This server acts on real IAM with your AWS credentials; scope the profile tightly and run it only on a trusted host. | ✓Sessions start in read-only mode. Write operations require explicit elevation and out-of-band one-time passcode confirmation — preventing accidental changes to production auth infrastructure. The server has access to your Descope project including user PII, tenant config, and auth secrets; scope usage to least-privilege workflows. |
| Privacy notes | ✓User identities, authentication logs, session details, workspace settings, and security configuration may be sent through tool calls. | ✓The local MCP server can send selected tenant operations to the Auth0 Management API and return application metadata, API identifiers, Actions code, form configuration, log events, user identifiers, IP addresses, and authentication error details into the model conversation. Prompts, MCP client logs, Claude transcripts, terminal history, screenshots, and issue comments can retain Auth0 resource names, tenant domains, client IDs, redirect URLs, organization names, and troubleshooting details outside Auth0's normal audit and retention controls. Do not paste client secrets, access tokens, refresh tokens, private keys, production user records, password-reset links, session cookies, or full log payloads into the conversation. Auth0 says the server stores credentials in the system keychain and redacts sensitive response fields such as client secrets and tokens. Still review assistant output before copying it into tickets, commits, runbooks, or shared chats. The server collects anonymized analytics by default according to Auth0's README. Set `AUTH0_MCP_ANALYTICS=false` when analytics collection is not approved for the environment. | ✓IAM user/role/group names, ARNs, policy documents, and account metadata can be returned through tool calls and exposed to the model. Access key IDs and other identity material may appear in responses; never expose secret access keys, and keep account identifiers and policy contents out of public prompts, issues, and screenshots. | ✓User profiles, tenant configurations, auth flow definitions, audit log entries, and API key metadata from your Descope project are surfaced in Claude's context. Authenticated via your Descope account — no API keys stored in the MCP configuration. |
| Prerequisites |
|
|
|
|
| Install | | | | |
| Config | | | | |
| Citations | ||||
| Claim | Unclaimed | Unclaimed | Unclaimed | Unclaimed |
Source-backed guides for putting this to work.
Design MCP servers with auth boundaries and narrow tools.
Loading live community signals…
A short, calm digest of reviewed Claude resources. Unsubscribe any time.