The onboarding path is the one that changes a working day: one request produces the application, the credentials on disk, the callback URLs resolved, and the SDK snippet for your framework — instead of a dashboard visit between every step.
Auth0's own MCP server for the Management API. It runs locally, signs in to your tenant through the OAuth device authorization flow, and keeps the credential in the system keychain rather than in a config file.
- Applications: auth0_list_applications, auth0_get_application, auth0_create_application and auth0_update_application cover web, native and single-page registrations
- APIs: auth0_list_resource_servers, auth0_get_resource_server, auth0_create_resource_server and auth0_update_resource_server manage resource servers, with auth0_create_application_grant tying an application to one
- Actions: auth0_list_actions, auth0_get_action, auth0_create_action and auth0_update_action, plus auth0_deploy_action to put a version live
- Forms: auth0_list_forms, auth0_get_form, auth0_create_form and auth0_update_form, plus auth0_publish_form
- Logs: auth0_list_logs searches the tenant log and auth0_get_log reads a single entry by ID
- Onboarding runs as one flow: auth0_onboarding creates an application for your framework and writes the credentials out through auth0_save_credentials_to_file, then hands to auth0_get_quickstart_guide, which resolves your callback URLs, updates the application, and returns the framework's integration code
An Auth0 tenant and Node.js v18 or higher. Running init opens a browser for the device authorization flow and writes the client config for you. Which tools are exposed is chosen at that point: it can be held to read-only, leaving just the list and get operations, or narrowed further by a name pattern such as 'auth0_list_*,auth0_get_*'.
One command — npx @auth0/auth0-mcp-server init