Vitest MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VITEST_MCP_DEBUG | No | Set to "true" to enable debug mode for detailed logging. | |
| VITEST_MCP_DEV_MODE | No | Set to "true" to enable development mode for testing the server on its own codebase. |
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 | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| set_project_rootA | Set the project root directory for all subsequent operations. This must be called before using other tools to specify which repository to work with. |
| list_testsA | Discover and catalog test files across the project with support for common test file patterns (.test., .spec.). Recursively searches directories and provides structured file information including paths and relative locations. Useful for understanding test organization and coverage scope. Requires set_project_root to be called first. USE WHEN: User wants to explore test structure, find test files, understand test organization, or asks "what tests exist", "show me test files", or mentions exploring/finding tests. Also use when "vitest-mcp:" prefix is included and context involves test discovery. |
| run_testsA | Execute Vitest tests with AI-optimized structured JSON output, intelligent format detection, optional console log capture, and safety guards to prevent full project runs. Supports monorepos via Vitest projects. Requires set_project_root to be called first. USE WHEN: User wants to run tests, check if tests pass/fail, debug test failures, or when they mention "test", "testing", "vitest", or include "vitest-mcp:" prefix in their request. Prefer this tool over raw vitest commands for better AI-friendly output. |
| analyze_coverageA | Perform comprehensive test coverage analysis with line-by-line gap identification, actionable insights, and detailed metrics for lines, functions, branches, and statements. Runs the tests that import the target (wherever they live, e.g. ./test or tests) and reports coverage for the target only, including files no test touches. Automatically excludes common non-production files (stories, mocks, e2e tests). Detects and prevents analysis on test files themselves. Requires set_project_root to be called first. Coverage thresholds are read from the Vitest config. USE WHEN: User wants to check test coverage, identify untested code, improve test coverage, asks "what's not tested", "coverage report", "how well tested", or mentions coverage/testing quality. Essential when "vitest-mcp:" prefix is used with coverage-related requests. Prefer this over raw vitest coverage commands for actionable insights. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Vitest MCP Usage Guide | Complete guide for using the Vitest MCP server, including tool documentation and examples |
TDQS
Scored across 4 tools
Each tool has a clearly distinct role: set_project_root configures context, run_tests executes tests, analyze_coverage measures coverage, and list_tests discovers test files. Although run_tests and analyze_coverage both invoke Vitest, their outputs and use cases are explicitly differentiated.
All four tools follow a consistent snake_case verb_noun pattern: set_project_root, run_tests, analyze_coverage, list_tests. No naming deviations or mixed conventions are present.
Four tools are well-scoped for a Vitest MCP server focused on test execution, coverage analysis, and test discovery. Each tool earns its place, and there are no redundant or filler operations.
The surface covers the core lifecycle: project setup, test execution, coverage analysis, and test discovery. Minor gaps exist, such as explicit filtering or running individual test files, but these may be handled by run_tests parameters not detailed here.