Working from a real profile is why sites treat the session as yours rather than as a bot, and why an already-signed-in service needs no login at all. The cost is exclusivity: Chrome will not share a profile directory, so you have to close your own windows before starting. On credentials, follow the project's own advice and put them in the keychain rather than the environment — the login tool will read them from there.
A Python browser automation server built around an existing Chrome profile rather than a fresh headless instance — so the sessions, cookies and extensions you already have are what the agent works with.
- Browser control: `tool_open_browser`, `tool_navigate` to a URL, `tool_close_browser`
- Element work: `tool_click` and `tool_type` by selector, `tool_get_text` for one element and `tool_get_elements` for many
- `tool_web_login` performs a login given a URL, credentials and selectors for the username, password and submit controls
- Login handling that stops rather than failing: it waits for you when a CAPTCHA appears, detects two-factor prompts, and reports why a login failed rather than returning a blank page
- Credentials stored in and retrieved from the system keychain with `tool_save_credentials` and `tool_get_credentials`, so they are not written into a config file
Python 3.12 and Google Chrome installed, with uv or Docker to run it; a one-line install through Smithery is available. CHROME_PROFILE_PATH points at your Chrome user data directory, which differs per operating system and is documented for Windows, macOS and Linux. Every other Chrome window using that profile must be closed before the server starts. Published on PyPI as mcp-chrome-server, version 0.1.0.
One command — npx -y @smithery/cli install @dlwjdtn535/mcp-chrome-server --client claude