Visionaire Engine vs PWA Debug Layer
A side-by-side look at the Visionaire Engine and PWA Debug Layer 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 PWA Debug Layer 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 PWA Debug Layer when
- You need dedicated capabilities in the Browser Automation domain.
- You prefer a local stdio subprocess transport.
- You want tools like
host_status, host_list_registrations, session_ping.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Browser Automation | Browser Automation |
| Quality signal | 64/100 · Good | 53/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 | 0 |
| Directory activity | 2 views 0 installs 0 upvotes | 0 views 0 installs 0 upvotes |
| Tools | 28 | 27 |
| Full listing | View Visionaire Engine | View PWA Debug Layer |
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
PWA Debug Layer tools 27
host_statusInstall/liveness state: registered IDs, manifest paths, launcher path, active connections. Cheap, idempotent. **Always call first.host_list_registrationsRead registered IDs; destructive cleanup to re-bootstrap.session_pingFull MCP → IPC → NMH → SW → page-world round-trip with typed `pageWorldError` codes + self-heal.pdl_check_setupDiagnose setup → `{ ok, gaps[], recommendations[] }` (CDP reachable, manifest installed, extension present, ID registered).pdl_browser_statusManaged launches (browser, profile mode, port, pid) with live debug-port re-probe + extension SW heartbeat.console_tailCursor-paginated, filterable tails of the persistent capture ring buffers (memory + disk spill).recent_eventsRecent captured events across kinds for quick verification.evaluateEvaluate an expression in the page world.session_recordrrweb session recording + cursor-paginated replay.source_map_resolveResolve generated stack frames to original `src/…:line:col`.settings_list_schemaRead the typed settings schema; get/set values (allowlist, capture filters, disk-spill, etc.).sw_statusService-worker registrations: installing/waiting/active versions, `updateViaCache`, controller, and whether an update is stuck **waiting** (the #1 "why isn't my update showing").- +15 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"
]
}
}
}
PWA Debug Layer
{
"mcpServers": {
"pwa-debug-layer": {
"command": "npx",
"args": [
"-y",
"chrome-devtools-mcp@latest"
]
}
}
}
Frequently asked questions
Visionaire Engine is categorized under Browser Automation and uses a local stdio subprocess. PWA Debug Layer belongs to Browser Automation and uses a local stdio subprocess. Pick Visionaire Engine for browser automation work and PWA Debug Layer 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. PWA Debug Layer 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 pwa-debug-layer 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. PWA Debug Layer has 53/100 (Good) with 0 views, 0 installs and 0 GitHub stars.
