Vitest MCP Server
An MCP server that lets LLM clients run scoped Vitest tests, discover test files, and analyze line-by-line coverage with token-efficient output.
set_project_root – Set the repository root (required first); supports switching between multiple repos in one session.
list_tests – Recursively discover test files (
.test.*,.spec.*) across the project or a specific directory.run_tests – Execute tests for a target file/directory with summary or detailed output, optional
[stdout]/[stderr]console log capture, and Vitest project selection for monorepos.analyze_coverage – Report line/function/branch/statement coverage for a source target, with summary or detailed line-by-line gap insights, exclusion globs, project scoping, and config-based thresholds.
Safety guards – Blocks full-project runs, watch mode, and invalid Vitest commands to protect context.
AI-friendly output – Structured JSON results with smart format detection instead of raw Vitest noise.
Runs within a Node.js environment (requiring Node.js 18+) to provide test execution capabilities and coverage analysis tools for JavaScript/TypeScript projects.
Provides AI-optimized testing tools for Vitest including structured output, visual debugging context, and intelligent coverage analysis with tools for test discovery, execution, and gap analysis.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Vitest MCP Server run tests for the login component and show me any failures"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🧪 Vitest MCP Server
MCP Vitest runner with LLM-optimized test output, log capturing, and line-by-line coverage analysis.
Table of Contents
Related MCP server: Vitest MCP Server
😢 The Problem with LLMs and Testing 😢
Noisy test output - Raw Vitest output can be extremely verbose eating up tokens/context with useless information.
Full test suite runs - LLMs sometimes forget to limit the scope of the test run, causing full test suite runs to be executed.
Buried console logs - Console logs can be hidden in test output, making it inefficient for LLMs to debug test failures.
Raw coverage files - Raw coverage files are too large for AI to parse.
Watch mode - LLMs get stuck when vitest runs in watch mode.
✨ Key Features ✨
Smart Test Results with adaptive, structured output to limit noise.
Console Log Capture to prevent logs from getting lost in test output.
Coverage Analysis with line-by-line gap insights.
Multi-Repository Support in a single session with context switching.
Safety Guards prevent full project runs, watch mode, invalid vitest commands, and context hogging.
🚀 Quick Start 🚀
The Vitest MCP server can be used with any MCP-compatible IDE or tool and works with all Javascript or Typescript Vitests. The basic configuration is:
{
"mcpServers": {
"vitest": {
"command": "npx",
"args": ["-y", "@djankies/vitest-mcp"]
}
}
}⚠️ Note: The above example may not be valid for all MCP clients. Verify your client's specific setup instructions.
🛠️ Client-Specific Setup
Select your preferred IDE or tool from the setup guides below:
Configuration Methods
Claude Code supports multiple configuration approaches:
Method 1: CLI Wizard (Interactive)
# Add server with interactive prompts
claude mcp add vitest -- npx -y @djankies/vitest-mcp
# Add to project scope (shareable with team)
claude mcp add --scope project vitest -- npx -y @djankies/vitest-mcpMethod 2: Direct Configuration File
Create or edit .mcp.json in your project root:
{
"mcpServers": {
"vitest": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@djankies/vitest-mcp"],
"env": {}
}
}
}Configuration Scopes
Local (default): Personal, project-specific - stored in user settings
Project: Team-shared - stored in
.mcp.jsonin project rootUser: Available across all projects - global configuration
Setup Steps
Navigate to your project directory
Choose either CLI or file-based configuration
For CLI: Run
claude mcp add vitest npx -y @djankies/vitest-mcpFor file: Create
.mcp.jsonwith the configuration aboveVerify with
/mcpcommand in Claude Code to see connection status
Usage
Once configured, use the MCP server naturally in your conversations:
"Set the project root to this directory"
"Run the auth component tests"
"Show me the test coverage gaps"
Configuration Location
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
Example Configuration
{
"mcpServers": {
"vitest": {
"command": "npx",
"args": ["-y", "@djankies/vitest-mcp"]
}
}
}Setup Steps
Open Claude Desktop
Navigate to File → Settings → Developer
Click Edit Config
Add the configuration above
Save and restart Claude Desktop
Look for the MCP indicator (🔌) in the conversation input
Configuration Methods
Workspace:
.vscode/mcp.jsonin your projectGlobal: Run command
MCP: Open User Configuration
Example Configuration
{
"mcpServers": {
"vitest": {
"command": "npx",
"args": ["-y", "@djankies/vitest-mcp"],
"type": "stdio"
}
}
}Setup Steps
Install VS Code 1.86+ with GitHub Copilot
Open Command Palette (
Cmd/Ctrl + Shift + P)Run
MCP: Add ServerSelect Workspace Settings or Global
Add the configuration and save
Access via Copilot Chat: Add Context → MCP Resources
Configuration Location
Project:
.cursor/mcp.jsonin your project directoryGlobal:
~/.cursor/mcp.jsonfor all workspaces
Example Configuration
{
"mcpServers": {
"vitest": {
"command": "npx",
"args": ["-y", "@djankies/vitest-mcp"]
}
}
}Setup Steps
Create the configuration file in your preferred location
Add the server configuration
Restart Cursor
The MCP server will be available in Cursor's AI chat
Use natural language to run tests: "Run the auth component tests"
Configuration Location
Similar to Cursor, but use serverUrl instead of url for remote servers
Example Configuration
{
"mcpServers": {
"vitest": {
"command": "npx",
"args": ["-y", "@djankies/vitest-mcp"]
}
}
}Setup Steps
Open Windsurf Settings (
Cmd/Ctrl + ,)Navigate to Cascade settings
Add MCP server configuration
Reload MCP servers to activate
Configuration via Cline UI
Example Configuration
{
"mcpServers": {
"vitest": {
"command": "npx",
"args": ["-y", "@djankies/vitest-mcp"]
}
}
}Setup Steps
Open VS Code with Cline extension installed
Click the Cline icon in the sidebar
Click MCP Servers → Configure MCP Servers
Add the vitest-mcp configuration
Save and reload VS Code
Access through Cline's chat interface
3. Use It 🎮
Once configured, you can use natural language to interact with your tests:
"Run the tests for this component"
"Debug this test file"
"Analyze the coverage for this file"
Or prepend your message with vitest-mcp: to ensure the tools are used:
"vitest-mcp: run tests for this component"
"vitest-mcp: debug this test file"
"vitest-mcp: analyze coverage for this file"
📋 Requirements
Node.js: 22.12+ 🟢
Vitest: 3.x, 4.x or 5.x installed in your project 🧪 (each major is tested in CI against real projects)
Coverage:
@vitest/coverage-v8or@vitest/coverage-istanbul, same major version as Vitest (for coverage analysis) 📊
npm install --save-dev vitest @vitest/coverage-v8The server always runs your project's own Vitest (resolved from node_modules, including hoisted monorepo installs). It never downloads Vitest or runs commands through a shell.
🧰 Tools
set_project_root
🚨 Required first - Set the project root for all operations.
Parameter | Type | Required | Description |
| string | Yes | Project root path |
list_tests
List test files in your project. Helps keep LLMs from slipping back to using command line tools while working with tests.
Parameter | Type | Required | Description |
| string | No | Directory to search for test files (defaults to the project root) |
run_tests
Execute tests with structured output.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | File or directory to test |
| string | No | Output format: "summary" or "detailed" (auto-detects based on results) |
| boolean | No | Include console output with |
| string | No | Vitest project name for monorepos |
analyze_coverage
Analyze test coverage with gap insights.
Parameter | Type | Required | Description |
| string | Yes | Source file or directory to analyze coverage for |
| string | No | Output format: "summary" (overview only) or "detailed" (includes line-by-line coverage) |
| string | No | Only use tests from this Vitest project (e.g. |
| string[] | No | Patterns to exclude from coverage (e.g., ["**/.stories."]). Replaces your config's |
Note: Coverage thresholds should be configured in your
vitest.config.tsfile, not via MCP parameters.
The tool runs every test that imports the target (vitest related), wherever your tests live (./test, __tests__, next to the source...), and reports coverage for the target only, including files that no test touches. Reports are written to a temporary directory, so your own coverage/ output is left alone. Test utilities, mocks, stories, and e2e files are excluded automatically.
🔄 Multi-Repository Support
// Project A
set_project_root({ path: "/path/to/frontend" })
run_tests({ target: "./src" })
// Project B
set_project_root({ path: "/path/to/backend" })
run_tests({ target: "./src" })🪝 Claude Code Hook
Automatically redirect Vitest commands to MCP tools:
# Run from project root
curl -o .claude/vitest-hook.sh https://raw.githubusercontent.com/djankies/vitest-mcp/refs/heads/main/.claude/vitest-hook.sh
chmod +x .claude/vitest-hook.shThen add to your project's .claude/settings.local.json:
{
"hooks": {
"PreToolUse": [{
"matcher": "Bash",
"hooks": [{ "type": "command", "command": ".claude/vitest-hook.sh" }]
}]
}
}The hook can be bypassed with the BYPASS_VITEST_HOOK environment variable:
BYPASS_VITEST_HOOK=1 npm testOr export for entire session:
export BYPASS_VITEST_HOOK=1🤖 LLM instructions
Encourage claude or your ide to use the tools correctly: CLAUDE.example.md
⚙️ Configuration
Vitest Configuration Priority
If your project has a vitest.mcp.config.* file (.ts, .mts, .cts, .js, .mjs or .cjs), the MCP server passes it to Vitest with --config. Otherwise Vitest finds your normal vitest.config.* / vite.config.* as usual.
This allows you to have a dedicated MCP-specific configuration that won't interfere with your regular development workflow:
// vitest.mcp.config.ts
import { defineConfig, mergeConfig } from 'vitest/config';
import baseConfig from './vitest.config';
export default mergeConfig(baseConfig, defineConfig({
test: {
// MCP-specific settings, e.g. a longer timeout for AI-driven runs
testTimeout: 30000,
},
}));Reporters, coverage output and console capture are set by the server on the command line, so you don't need to configure them.
Coverage Thresholds
To enable coverage threshold reporting in the analyze_coverage tool, just configure in your Vitest configuration file:
// vitest.config.ts or vitest.mcp.config.ts
import { defineConfig } from 'vitest/config';
export default defineConfig({
test: {
coverage: {
provider: 'v8',
reporter: ['text', 'json', 'html'],
thresholds: {
lines: 90,
functions: 85,
branches: 80,
statements: 90
}
}
}
});💡 Note: Coverage analysis is always available regardless of threshold settings. Threshold reporting just helps keep your LLM on target.
Vitest-MCP Configuration File
Optional .vitest-mcp.json in home or project directory:
{
"safety": {
"allowedPaths": ["/Users/username/Projects"]
},
"testDefaults": {
"format": "detailed",
"timeout": 60000
}
}Priority Order
Configuration is merged in the following order (highest priority first):
Command-line flags
Environment variables
Configuration file
Built-in defaults
🧑🏻💻 Development Mode & Debugging
Enable Debug Mode
Set the debug environment variable for detailed logging:
VITEST_MCP_DEBUG=trueOr in your MCP config file:
{
"mcpServers": {
"vitest": {
"command": "npx",
"args": ["-y", "@djankies/vitest-mcp"],
"env": {
"VITEST_MCP_DEBUG": "true"
}
}
}
}Development Mode
Enable to test the server on its own codebase:
# Set in .env.development, or in your mcp config file
VITEST_MCP_DEV_MODE=true🔧 Troubleshooting
"Vitest not found" - Install it in the project you set as root: npm install --save-dev vitest
"Coverage provider not found" / "does not match Vitest" - Install the provider matching your Vitest major, e.g. npm install --save-dev @vitest/coverage-v8@4 for Vitest 4 📊
Hook issues - Bypass with: BYPASS_VITEST_HOOK=1 npm test
Found a bug? Submit a bug report, please, and thank you.
🤝 Contributing
Releases are automated with semantic-release: merging to main publishes a new version when it contains fix: (patch), feat: (minor) or breaking (feat!:) commits, and updates the CHANGELOG. Please write commit messages in the Conventional Commits format; a commit hook and CI check them.
📜 License
MIT — See LICENSE.
Available Tools
4 toolsanalyze_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.
Inputs: target (required), format, exclude, project.
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.
Inputs: path.
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.
Inputs: target (required), format, project, showLogs.
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.
Inputs: path (required).
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
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.
Maintenance
Related MCP Connectors
Direct access to Cypress tests results and accessibility reports in your AI workflow.
Approved test intent, reviewed Playwright automation and run evidence, inside your editor.
Writes adversarial test suites for AI-built code. Your agent's test engineer.
No-code, AI-assisted UI testing: record new tests, run existing ones, and monitor the results.
Related MCP Servers
- FlicenseCqualityDmaintenanceEnables comprehensive analysis of JavaScript/TypeScript project testing setups by detecting frameworks like Jest, Vitest, and Cypress, analyzing test coverage metrics, and generating actionable recommendations for improving test quality. Provides detailed insights into test structure, dependencies, and coverage thresholds with visual feedback.31-
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to run Vitest tests and analyze code coverage, supporting test-driven development workflows with tools for test execution and coverage analysis.207 npm3MIT
- AlicenseAqualityDmaintenanceWraps existing test frameworks (Jest, Vitest, Pytest) and exposes structured, LLM-optimized results via MCP tools with progressive disclosure and diff-aware execution.111MIT
- AlicenseAqualityBmaintenanceEnables AI assistants to create, run, autocorrect, and monitor Playwright tests for your app with a local dashboard, credential vault, and public status page.16MIT