Vibe Testing
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_codebaseA | 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. |
| loginC | 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. |
| scan_page_elementsA | 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. |
| explore_pageA | 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. |
| execute_scenarioA | 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. |
| get_coverageA | 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. |
| generate_reportA | 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 report auto-opens in the browser. |
| take_screenshotA | 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. |
| suggest_testsA | 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. |
| run_full_testA | 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). |
| run_convergeA | 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. |
| get_contextA | 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. |
| cleanupA | Close all open browsers and reset the session state. Call when done testing. |
| configureB | Idempotently configure a project and detect its framework, running server, and authentication method. Existing VIBE.md and vibe.config.json files are preserved. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Most tools have clearly distinct purposes, but scan_codebase, get_coverage, and suggest_tests all return coverage gaps and test suggestions, creating real selection ambiguity. The descriptions clarify prerequisites somewhat, but an agent could still reasonably call the wrong one.
The majority of tools follow a clear imperative verb_noun snake_case pattern like scan_codebase, execute_scenario, and generate_report. However, login, cleanup, and configure are bare verbs, and run_converge uses a verb where a noun object would be more consistent with run_full_test.
Fourteen tools is within a reasonable range for a comprehensive testing workflow and most map to distinct phases. It feels slightly heavy because several tools overlap around coverage/suggestions and there is an all-in-one orchestrator, but no tool feels entirely superfluous.
The core web-testing lifecycle is well covered: configuration, login, codebase scanning, element discovery, scenario execution, coverage analysis, reporting, and cleanup. Minor gaps include no explicit way to retrieve past test results outside of generated reports or to abort a long-running convergence run.