The tool descriptions steer away from screenshots on purpose: get_element_attribute and execute_script are named as the way to verify state, the accessibility://current resource as the way to understand page content, and take_screenshot is reserved for questions about layout and styling. diagnostics then supplies what a screenshot never could — the JavaScript error and the network activity behind the failure — in the same session that produced it. That combination makes it usable for reproducing a bug report, not only for scripted clicking.
A Selenium WebDriver session exposed as 18 tools: browser lifecycle, element interaction by locator, state readback, and browser-level diagnostics captured over WebDriver BiDi.
- A browser session you start with your choice of browser and options, and close when finished
- Element interaction by locator with a timeout: mouse actions, typing that clears the field first, keyboard key presses, and file upload through a file input
- State readback for assertions — an element's text, an element's attribute, or arbitrary JavaScript that can batch several reads into one call
- Console logs, JavaScript errors and network activity captured over WebDriver BiDi, retrieved as a group and clearable
- The awkward parts of real pages: window and tab management, switching into a frame and back, and dismissing an alert, confirm or prompt dialog
- Cookie control on the live session — add one for the current domain, read all or one by name, delete one or all
- Screenshots to a path when the question is visual layout or styling
A browser on the machine for Selenium to drive, chosen at the time you start the session. No credentials and no account. MIT licensed.
One command — npx -y @angiejones/mcp-selenium@latest