MCP.Market

Vibe Test — Browser Testing Agent MCP server

by AishwaryShrivastav·io.github.AishwaryShrivastav/vibe-testing·v0.4.6·6 stars

Code-aware browser testing agent — 14 Playwright tools for AI code editors via MCP

B74/100grade B
What users say
No reviews yet
Be the first
Safety scan
B74/100

full report

Adoption
Growing

6 stars107 downloads/wk

Reviews

Write one

Nobody has reviewed Vibe Test — Browser Testing Agent yet.

If you have run it, two minutes of your experience saves the next person an afternoon.

Vibe Test — Browser Testing Agent tools (14, 3 write)

write = sends, deletes, buys or posts

Read from the package source without running it. The installed server may list more.

  • cleanup

    Close all open browsers and reset the session state. Call when done testing.

  • configure

    Idempotently configure a project and detect its framework, running server, and authentication method. Existing VIBE.md and vibe.config.json files are preserved.

  • execute_scenariowrite action

    Execute a single test scenario (a sequence of navigate/fill/click/assert steps) and return detailed results with step-by-step logs, screenshots after each state-changing step, API errors observed, and the final page state. The editor LLM can construct scenarios based on scan_codebase output or create custom ones.

  • explore_page

    Perform a full interactive exploration of a page: discover all elements, click buttons, fill inputs, test tabs, observe API calls, and report what happened. Returns detailed interaction outcomes, API observations, and screenshots. This is the "senior tester" mode — it tries every element and reports what works and what breaks.

  • generate_report

    Generate a self-contained HTML test report with embedded screenshots from all collected results, explorations, and coverage data. Returns the report file path and a text summary. The report includes: pass/fail results per scenario, step-by-step screenshots, element exploration findings, API error monitoring, and coverage gap suggestions. Call this after executing scenarios and explorations. The re

  • get_context

    Retrieve the most relevant source files for a given feature or route. Returns actual source code (budget-capped) so you understand real field names, API endpoints, and component structure before writing test steps. Call this after scan_codebase when you want to write precise test scenarios for a specific feature — it eliminates guesswork about selectors and form fields.

  • get_coverage

    Return the current test coverage map, identified gaps, and suggested tests. Prerequisite: scan_codebase must have been called first. Returns JSON with: coverage entries per route (tested/untested, test frameworks used), gap analysis with priority scores (high/medium/low), and concrete test suggestions for missing coverage. Use this to understand what has been tested and what still needs testing.

  • login

    Establish an authenticated browser session by executing a login scenario. Returns the post-login URL, token state, and a screenshot. Uses saved credentials from previous runs if available, or accepts provided credentials.

  • run_convergewrite action

    Iterative coverage: runs the full baseline suite, then automatically runs follow-up rounds targeting coverage gaps and failed scenarios until pass rate and gap thresholds are met (or max rounds reached). Use for "keep testing until coverage is good". Returns results across all rounds and opens the final HTML report.

  • run_full_testwrite action

    Run a complete end-to-end test suite: scan codebase → generate scenarios → execute all → explore pages → generate report. This is the all-in-one command. For more granular control, use the individual tools (scan_codebase, login, explore_page, execute_scenario, generate_report).

  • scan_codebase

    Analyze a project's codebase to understand its structure, routes, forms, components, existing tests, and coverage gaps. Returns a ProductModel with routes, behaviours, coverage map, gaps, and generated test scenarios. Call this first before any testing.

  • scan_page_elements

    Navigate to a specific page and discover all interactive elements (buttons, links, inputs, selectors, checkboxes, tabs). Returns a structured list of elements with their types, text, selectors, and disabled state. Also returns a screenshot of the page. Use this to understand what's on a page before deciding what to test.

  • suggest_tests

    Analyze codebase features, existing test coverage, and results from previous runs to suggest concrete test scenarios that should be written or executed. Returns prioritized, executable scenario objects with steps. Use this after scan_codebase to understand what testing is missing and get ready-to-run scenarios.

  • take_screenshot

    Navigate to a URL and take a screenshot. Returns the screenshot as a base64 data URI that the editor LLM can see and reason about. Use this for quick visual verification.

Public scan report

scanner v0.1.10 · 2026-10-15 · same rubric, same numbers if you re-run it

1 high
  • Code scan77 source files scanned13/25
  • –Live reliabilityno gateway calls yet and no remote to proben/a
  • –Tool poisoningtools not inspected (local package is not executed); not countedn/a
  • Auth qualitylocal package, no credentials required12/15
  • Maintenancelast push 0 days ago15/15
  • Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Findings (1)

  • highShell command built from a string (injection risk)exec.shell-concat
    dist/cli.js: …32' ? 'start' : 'xdg-open'; exec(`${openCmd} "${reportPath}"`); logger.succe…
Overall 74/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON

How Vibe Test — Browser Testing Agent compares

Against every graded Scraping and browsing MCP server, from our own scans and uptime checks. Updated after each scan run.

Safety score
74/100
higher than 40% of 866 Scraping and browsing servers
Tools
14
the typical Scraping and browsing server has 6
Tools that change things
21%
typical: 0%. Fewer write tools means less an agent can break
GitHub stars
6
more than 75% of 583 Scraping and browsing servers
Downloads a week
107
more than 56% of 309 Scraping and browsing servers with a package

What its tools let an agent do: 10 read · 1 create · 3 run or deploy

Release history: 2 versions in the registry since 2026-09-14, latest 2026-09-21, typically one every 7 days.

Install Vibe Test — Browser Testing Agent in Claude Code, Cursor or VS Code

Runs npx -y vibe-testing on your machine. Read the scan report first; the gateway never runs local packages.

claude mcp add vibe-testing -- npx -y vibe-testing
Add to Cursor

What the publisher says

From the Vibe Test — Browser Testing Agent repository's README, as published. We do not edit it. Read it on GitHub

vibe-testing

Code-aware browser testing for AI coding agents.

Product site · npm · MCP Registry · Launch status

vibe-testing reads your codebase so tests use your real routes and field names, runs them in a real Playwright browser, remembers what broke, and tells you what your last change fixed or regressed. It works as an MCP server that gives your editor (Claude Code, Cursor, Windsurf, VS Code Copilot, Roo Code) 13 testing tools, or as a standalone CLI.

The repository is also an Agent Plugin with a release-qa skill. Compatible agents get both the testing tools and a senior-QA workflow for coverage, evidence, regression checks, and a clear release verdict.

cd /path/to/your/project
npx vibe-testing@latest init

Then open your editor and say:

"Scan this codebase and test it against http://localhost:3000"

What code-aware testing adds

Playwright MCP gives your agent hands. vibe-testing gives it a testing workflow: code-derived scenarios, memory across runs, and a report. Two things a stateless browser tool cannot do:

1. Run it twice and it tells you what you broke. Every run writes .vibe/run-snapshot.json and diffs it against the previous run. Every scan writes .vibe/route-manifest.json and diffs your routes. The second run prints regressions and fixes instead of a wall of results:

Changes since last run
  Fixed:      /login
  Regression: /checkout
  New:        /admin/users

The same diff reaches your editor as snapshotdiff on runfulltest and runconverge, and as routechanges on scancodebase, so the agent can flag "checkout broke after that commit" without anyone scrolling a report. Flaky routes, working selectors, and measured timeouts are also remembered between runs.

2. Zero LLM calls inside the tool. Pass/fail verification is heuristic: URL changes, toast detection, API errors. Your editor's model decides what to test; vibe-testing does the browsing and checking. No API key, no per-run cost beyond the editor subscription you already pay for.

Contents

  • How it works
  • MCP setup (per editor)
  • MCP tools reference
  • Recommended workflow
  • init command
  • CLI commands
  • VIBE.md, project guidance
  • Configuration (vibe.config.json)
  • Supported frameworks
  • Memory and regression detection
  • FAQ

How it works

npx vibe-testing@latest init
        |
Registers 13 MCP tools in your editor
        |
You ask: "Test the checkout flow"
        |
AI calls: scan_codebase -> get_context("checkout") -> login -> explore_page -> execute_scenario -> generate_report
        |
HTML report opens in browser with screenshots of every step

No test cases to write. The AI reads your source code to understand real field names and routes, opens a browser, tests everything, and shows you what's broken.

init also:

Shortened. The full README is on GitHub.

Nothing above is checked by us. What we check is on the safety report.

Vibe Test — Browser Testing Agent: common questions

Is Vibe Test — Browser Testing Agent MCP server safe?
Mostly: it is graded B (74/100). Read the Vibe Test — Browser Testing Agent safety report
How do I install Vibe Test — Browser Testing Agent?
It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.
Does Vibe Test — Browser Testing Agent need an API key?
Not as far as the registry entry and our scan can tell: no credentials are declared or required.
Is Vibe Test — Browser Testing Agent maintained?
The last commit was 20 days ago (2026-10-15). The latest release is v0.4.6.
What can I use instead of Vibe Test — Browser Testing Agent?
Servers from other publishers that do the same job: GrowBlocks Dev Kit MCP server, SeleniumBase MCP server and invisible_playwright_mcp MCP server. Compare all Vibe Test — Browser Testing Agent alternatives.
How does Vibe Test — Browser Testing Agent compare with other Scraping and browsing MCP servers?
safety score 74/100 (higher than 40% of 866 Scraping and browsing servers); tools 14 (the typical Scraping and browsing server has 6); tools that change things 21% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.

Alternatives to Vibe Test — Browser Testing Agent

Same job from other publishers: the closest match first, then the best rated.

All Vibe Test — Browser Testing Agent alternatives →
  • GrowBlocks Dev Kit
    Build, play-test with screenshots, and ship three.js browser games on GrowBlocks.
    A
  • SeleniumBase MCP
    Stealthy browser automation, testing, and web-scraping via CDP Mode.
    A
  • invisible_playwright_mcp
    AI browser agent: browses, clicks, types, and reads real web pages from plain-English instructions.
    A
  • CloakBrowser MCP
    Playwright MCP-compatible browser automation bridge for CloakBrowser Chromium.
    B
  • FableCut
    Zero-dependency browser video editor AI agents drive via a JSON timeline over MCP; ffmpeg export.
    A