Visionaire Engine vs Webdriverio MCP
A side-by-side look at the Visionaire Engine and Webdriverio MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Visionaire Engine for browser automation work as a local process; choose Webdriverio MCP for browser automation as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Visionaire Engine when
- You need dedicated capabilities in the Browser Automation domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You want tools like
connect, navigate, set_viewport.
Choose Webdriverio MCP when
- You need dedicated capabilities in the Browser Automation domain.
- You prefer a local stdio subprocess transport.
- You want tools like
enable_tools, start_session, attach_session.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Browser Automation | Browser Automation |
| Quality signal | 64/100 · Good | 64/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | No auth required | Not declared |
| Pricing | Free | Not declared |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 5 | 43 |
| Directory activity | 2 views 0 installs 0 upvotes | 2 views 0 installs 0 upvotes |
| Tools | 28 | 40 |
| Full listing | View Visionaire Engine | View Webdriverio MCP |
Tools & capabilities
Visionaire Engine tools 28
connectALWAYS the first call: start (or restart) the browser session — launch a local Chrome by default, or attach to the user's real, logged-in browser via browserUrl (e.g. http://127.0.0.1:9222, for pages behind auth like wp-admin or a dashboard). Pass url to load a page immediately. Every other tool needs a live session; if a tool reports no session or a wedged browser, call connect again to reset.navigateNavigate the connected tab to a URL — or, with no url, hard-reload the current page. Pass bypassCache: true when a stale cached stylesheet/script keeps being served (disables the browser cache for the rest of the session). All element uids from earlier snapshots become stale — take a fresh page_snapshot afterwards.set_viewportEmulate a viewport size (and optional deviceScaleFactor) on the connected tab, then re-inspect. Use for responsive bugs — 'it breaks on mobile', 'the menu is wrong at tablet width', anything behind a media query — since resizing can change which @media rule wins. Follow with a fresh page_snapshot / explain_styles at the new size.page_snapshotToken-budgeted census of the rendered page — a nested, uid-keyed element tree with geometry and visibility flags. Call this FIRST after connect to orient yourself and to obtain the stable uids every other tool targets. Reach for it whenever you do not yet know the page structure or an element uid. To find one specific element by description use find_elements; to see the page visually use annotated_screenshot.page_originsInventory of every stylesheet (URL, byte size, origin, source-map presence) plus platform detection — WordPress version, theme/child theme, page builder (Elementor/Divi), and CSS optimizer. Use before proposing edits to learn where the CSS actually lives, when a file:line points at a generated/minified bundle and you need the true source, or to answer 'is this WordPress/Elementor?' and 'which stylesheet owns this?'.inspect_elementThe 'WHAT' for one element: box model (margins/padding/border), key computed styles as authored → used values, a visibility verdict, and layout context. Use when you need an element's current rendered state — its real size, spacing, or whether it is actually visible/where it sits. These are the values the page ACTUALLY renders, so it catches the common case where the source rule you'd edit is overridden or never applied. For 'WHY it looks like this / which rule wins' use explain_styles; for 'which ancestor constrains its size or position' use inspect_ancestors.explain_stylesThe core 'WHY': a per-property cascade verdict naming the winning CSS declaration and every loser with the exact reason it lost (specificity, !important, source order, inline, layer), each attributed to file:line or a WordPress/Elementor/Customizer origin. Reach for this whenever a style is wrong or 'won't apply' — wrong color/font/size/spacing, 'something is overriding my rule', 'where does this value come from', 'which rule do I edit'. Prefer this over grepping the source for a style bug: source search finds candidate rules, but only the live cascade shows which one actually WINS on a layered stack — so diagnose here before editing CSS you assume is the cause. Each winner also reports its BLAST RADIUS — how many other elements that rule styles (so you change THE button, not all buttons) — plus a scoped selector that targets just this element, with a specificity verdict. Pass an optional property (e.g. 'margin-bottom') to focus.inspect_ancestorsWalk an element's ancestor chain for ONE concern — width, height, position, overflow, or stacking — and flag the ancestor that is the binding constraint. Use when the cause lives ABOVE the element: it's too wide/narrow, clipped or cut off, won't scroll, is mysteriously positioned, or a z-index has no effect (trapped in an ancestor's stacking context). Complements explain_styles, which explains the element's own winning rules.find_elementsDeterministic search by visible text, CSS selector, ARIA role, and/or screen region → compact uid-keyed matches; anchors include their resolved href, so find_elements{role:'link'} lists the page's links WITH destinations (then navigate to browse them). Criteria are AND-combined by default; pass match:'any' for a union (OR) when over-specifying returns nothing, and visibleOnly:false to include display:none/hidden elements. Use to locate the element a user described in words ('the Subscribe button', 'the header nav') before inspecting it. Prefer this (or page_snapshot) over guessing a selector. For a point in a screenshot use node_at_point; to have the human physically click the element use pick_element.node_at_pointMap viewport coordinates (x, y) to the element there: uid, identity, and the full ancestor uid chain. Use to turn a coordinate — e.g. a spot you located in an annotated_screenshot, or pixel coords the user gave — into a concrete element and uid.annotated_screenshotScreenshot in two modes: an overview with numbered marks burned in, where mark N equals uid eN (mark 17 = e17); or an element-scoped crop via clipTo (uid|selector|x,y) with optional padding, scale (0.5..4 zoom for tiny elements), and annotate:false for a clean unlabeled crop. Use when text tools are not enough and you need to SEE the page while keeping pixels tied to elements — spatial or visual-layout questions ('things overlap', 'the layout looks off'), to zoom in on one small element, or to confirm which element is which. Then target elements by their uid.style_diffBEFORE/AFTER comparison for one element: record its styles into a named slot, change something, compare — only the properties that changed are reported. Reach for it whenever you ask 'did my fix actually change anything?' or need to prove what an edit / inject_css patch / viewport change / interaction altered. The loop: style_diff{mode:'record'} → apply the change → style_diff{mode:'compare'}. Confirms a fix moved exactly the property you intended, and nothing else.- +16 more on the listing page
Webdriverio MCP tools 40
enable_toolsAdd a group of tools: `mocks`, `cookies`, `device`, `extensions`, `attach`, `elements`, `cloud-appsstart_sessionStart a browser, local Electron application, or mobile app session; `attach: true` retains the existing Chrome CDP connection modeattach_sessionAttach to an existing remote WebDriver/Appium session by ID without creating a new sessionlaunch_chromeLaunch a new Chrome instance with remote debugging enabled (for use with `start_session({ attach: true })`)close_sessionClose or detach from the current session (supports `detach: true` to disconnect without terminating)emulate_deviceEmulate a mobile/tablet device preset (viewport, DPR, UA, touch); requires BiDi sessionopen_web_extensionInstall a web extension through WebDriver BiDi and open one of its extension pages so normal page tools can drive its UInavigateNavigate to a URL. In browsers the result shows the new page's interactive elements with refssnapshotThe page as an accessibility tree with refs (`button "Save" [ref=e3]`), interactive elements by default (plain text is dropped, `full: true` shows it); pass refs to `perform_actions` for several steps; `find` returns only the parts containing a text (link targets included), `full: true` adds all te…get_elementsGet visible, interactable elements with bounds. Supports `inViewportOnly` (default: true) and `includeContainers` (default: false). Mobile and Electron; listed after `enable_tools({ groups: ['elements'] })`, use `snapshot` firstget_accessibility_treeGet the accessibility tree with roles, names, and selectors. Electron-only; browsers use `snapshotget_screenshotTake a screenshot of the current page or screen (base64-encoded, auto-resized to max 2000px / 1MB)- +28 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Visionaire Engine
{
"mcpServers": {
"mi60dev-visionaire-engine": {
"command": "npx",
"args": [
"-y",
"visionaire-engine"
]
}
}
}
Webdriverio MCP
{
"mcpServers": {
"webdriverio-mcp": {
"command": "npx",
"args": [
"-y",
"@wdio/mcp@latest"
]
}
}
}
Frequently asked questions
Visionaire Engine is categorized under Browser Automation and uses a local stdio subprocess. Webdriverio MCP belongs to Browser Automation and uses a local stdio subprocess. Pick Visionaire Engine for browser automation work and Webdriverio MCP for browser automation.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Visionaire Engine is listed as free. Auth: no auth required. Webdriverio MCP has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add mi60dev-visionaire-engine and webdriverio-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Visionaire Engine has a quality signal of 64/100 (Good) with 2 views, 0 installs and 5 GitHub stars. Webdriverio MCP has 64/100 (Good) with 2 views, 0 installs and 43 GitHub stars.
