Auth0 MCP Server: Setup, Tools & Real Limits
Auth0’s official beta MCP server is useful for bounded tenant administration, but its write tools and narrow API coverage demand deliberate limits.
Auth0 MCP is Auth0’s official local server for letting an MCP-compatible agent inspect and change selected tenant configuration through the Management API. It can list applications, investigate logs, create APIs, and deploy Actions, but it remains beta software. Our recommendation: use read-only mode by default and keep production writes outside conversational workflows.
Table of contents
- What Auth0 MCP actually is
- What exists today
- Setup
- Tools you get
- Permissions and blast radius
- Real limits
- When not to use it
What Auth0 MCP actually is
Auth0 MCP is an adapter between an MCP client and the Auth0 Management API, not a new identity provider or an authentication layer for your own MCP server. The agent discovers named tools, supplies structured arguments, and receives structured API results from a local process.
In concrete terms, you can ask an assistant to find an application’s callback URLs, inspect failed login events, create a resource server, update an Action, or publish a Form. The process keeps the Auth0 access token out of the model-facing conversation; Auth0 says credentials are stored in the operating system keychain and sensitive response fields are redacted. The official repository documents this architecture and the complete supported-tool list.
That makes it an administrative interface, not merely a search connector. If you are comparing broader categories in our MCP capabilities guide, classify it as a tools server with consequential writes. I would use it to shorten diagnosis and development setup, but not let an agent freely reshape a live tenant.
What exists today
There is a first-party Auth0 MCP server today: the npm package is @auth0/auth0-mcp-server, maintained in Auth0’s public GitHub organization. You do not need to gamble on an anonymous community wrapper for the core use case.
The catch is maturity. Auth0 labels the project beta, says functionality may change without notice, offers limited beta support, and explicitly says it is not recommended for production or critical workloads. Its GitHub releases are still marked pre-release, so “official” should not be confused with “stable.” See the repository’s beta notice and releases.
My view is straightforward: this is a credible development and investigation tool, not an approved production control plane. Pinning a package version can reduce surprise, but it does not turn a beta interface into an SLA-backed product. For alternatives with a stronger vendor-maintained posture, browse the official MCP server collection, while remembering that first-party ownership alone does not settle operational risk.
Setup
The shortest safe setup is Node.js 18 or newer, an MCP client, an Auth0 tenant, and an Auth0 identity allowed to request only the scopes you need. Start with the initializer’s read-only option rather than accepting every tool.
- Run
npx @auth0/auth0-mcp-server init --read-only. - Complete the browser-based OAuth 2.0 device authorization flow and select the tenant. No scopes are selected by default; choose the read scopes required for applications, resource servers, Actions, logs, or Forms.
- Restart the MCP client and verify a harmless request, such as listing applications.
- Run
npx @auth0/auth0-mcp-server sessionwhen authentication looks stale, andnpx @auth0/auth0-mcp-server logoutwhen the session is finished.
The project’s authentication instructions say device authorization is unavailable for Private Cloud tenants. Those tenants must use client credentials with an Auth0 domain, client ID, and client secret; Auth0 advises short token lifetimes and limited Management API scopes. Avoid putting that secret in checked-in client configuration.
For a generic MCP client, this is the documented mcpServers shape, restricted to reads:
{
"mcpServers": {
"auth0": {
"command": "npx",
"args": ["-y", "@auth0/auth0-mcp-server", "run", "--read-only"],
"capabilities": ["tools"],
"env": {
"DEBUG": "auth0-mcp"
}
}
}
}
Client file locations differ, so use the server’s init --client ... route where supported or adapt the verified shape with our MCP config generator. The repository documents Claude Desktop, Claude Code, Cursor, Windsurf, VS Code, Gemini CLI, and Codex configurations; a restart is commonly required after installation.
Tools you get
The server exposes a focused slice of Auth0 administration: applications, resource servers, grants, Actions, logs, Forms, and project onboarding. The table below lists representative tools verified in Auth0’s current README, not guessed aliases.
| Tool | What it does | Risk |
|---|---|---|
auth0_list_applications | Lists or searches tenant applications | Read |
auth0_get_application | Gets one application’s configuration | Read |
auth0_create_application | Creates an Auth0 application | Write |
auth0_update_application | Changes application settings such as callback URLs | Write |
auth0_list_resource_servers | Lists configured APIs | Read |
auth0_create_application_grant | Grants an application API scopes | Write |
auth0_list_actions | Lists tenant Actions | Read |
auth0_deploy_action | Deploys an Action | Write |
auth0_list_logs | Retrieves tenant log events | Read |
auth0_get_log | Gets one log event by ID | Read |
auth0_list_forms | Lists Auth0 Forms | Read |
auth0_publish_form | Publishes a Form | Write |
Auth0’s supported-tools section also documents get, create, and update operations for several of these resources. The onboarding tools go further: auth0_onboarding creates an application and writes credentials to a project environment file, while auth0_get_quickstart_guide returns framework-specific integration guidance. I would keep onboarding disabled outside disposable development projects because it crosses tenant and local-filesystem boundaries.
Permissions and blast radius
Use two gates: limit the OAuth scopes and limit the tools exposed to the model. Either control alone is incomplete; a read-only tool list is safer, while a read-only token ensures an unexpected write path still fails at Auth0.
The server supports --read-only and --tools patterns, and read-only takes precedence when both are present. Auth0 also documents automatic redaction of fields such as client_secret and token, but redaction does not prevent destructive configuration changes. The project’s security guidance recommends minimum tool access and explains the equivalent AUTH0_MCP_READ_ONLY and AUTH0_MCP_TOOLS environment controls.
Use a dedicated integration identity or narrowly scoped M2M application so activity is attributable and human admin privileges are not inherited. A careless callback-URL update can break login or redirect behavior; an overbroad application grant can give a client access to API scopes it should not hold; a deployed Action can affect every login in its bound flow. Test writes in a non-production tenant, require human review, and record the before-and-after configuration.
Real limits
Auth0 MCP does not remove Management API pagination, rate limits, tenant limits, or the model’s context ceiling. It also exposes only the operations in its tool catalog, which is far less than the full Management API.
Large listings are the first practical failure point. Auth0’s Management API pagination guide says offset pagination is intended for collections of roughly 1,000 items or fewer; Public Cloud pages max out at 50 items and Private Cloud pages at 100. Log search is tighter: Auth0 documents no more than 100 logs per request and only 1,000 searchable results through pagination. Dumping every page into a conversation wastes context and may bury the event that matters, so filter by time, event type, application, user, or IP before retrieval.
Every tool call still consumes Management API quota. Limits vary by API, endpoint, tenant type, and subscription, and excess requests return HTTP 429; Auth0’s rate-limit policy warns that aggressive polling and rapid configuration updates can trigger throttling. An agent retry loop can therefore compete with deployment automation and operator tooling. Set a bounded task, avoid broad polling, and stop on repeated 429 responses.
Coverage is another hard boundary. The documented catalog has no general tools for deleting resources, managing users, connections, organizations, roles, rules, branding, or tenant settings. That may change during beta, but do not assume the model can perform an operation just because the underlying Management API can.
When not to use it
Do not use Auth0 MCP for repeatable production changes, bulk exports, continuous monitoring, or features outside its documented catalog. Use a reviewed API script or infrastructure-as-code workflow when determinism, diffs, retries, approvals, and rollback matter.
A plain script is better for migrating hundreds of records, applying the same configuration across tenants, or handling rate-limit backoff predictably. Use Auth0’s dashboard for a rare high-risk change when visual confirmation is valuable. If your actual goal is to secure an MCP server or AI agent rather than administer Auth0, use Auth0’s separate Auth for MCP documentation; that product handles OAuth-based access to your server, whereas Auth0 MCP manages an Auth0 tenant.
The trade-off is speed versus control. Natural-language administration is excellent for exploratory log investigation and bounded dev setup, but weaker than code for reproducibility. Among the best MCP servers, the right choice is not the one with the most write tools; it is the one whose failure mode your team can contain. For Auth0 MCP, I would approve read-only development use now and keep production mutation behind reviewed automation.