smart_login

Parameters

Example

Log in to https://myapp.com/login with user@example.com and password123

How It Works

1. Navigates to the login URL in a new browser session
2. Auto-detects the username/email input by checking:
   • input[type="email"], input[name="email"], input[name="username"]
   • input[id="email"], input[id="username"]
   • input[type="text"][autocomplete="username"], input[type="text"]
3. Auto-detects the password input: input[type="password"]
4. Fills both fields with browser and DOM-event fallbacks for brittle auth UIs
5. Submits with click, Enter, and form-submit fallbacks
6. Waits for navigation and checks the result
7. Reports one of three outcomes:
   • LOGIN SUCCESS — Redirected away from login page
   • LOGIN FAILED — Error message detected on page
   • LOGIN UNCERTAIN — Still on login page, no clear error

Response

Returns a screenshot of the page after login attempt, the status (SUCCESS/FAILED/UNCERTAIN), and a session ID.

The session ID can be used with all other browser_* tools to continue testing the authenticated flow.

Notes

• Start with auth_test_assist first when the task is website auth testing — it gives sign-in vs sign-up guidance and reusable inbox context
• Treat uncertain provider-specific flows as site evidence to record, not as universal auth rules
• Never guess credentials — always ask the user first
• If auto-detection fails, provide usernameSelector, passwordSelector, and/or submitSelector manually
• The session stays open after login for continued testing — call browser_close when done
• If the result is uncertain on Clerk or another multi-step auth UI, inspect network and console evidence, then use browser_fill, browser_press_key, or browser_evaluate manually
• Does not complete 2FA, captchas, or OAuth redirects by itself — use browser_fill, browser_click, solve_captcha, and check_inbox for those
• Use find_login_page first if you don't know the login URL