Skip to main content
Glama
djankies

Vitest MCP Server

by djankies
OverviewSchemaRelated ServersScoreDiscussions
TypeScript

🧪 Vitest MCP Server

CI

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-mcp

Method 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.json in project root

  • User: Available across all projects - global configuration

Setup Steps

  1. Navigate to your project directory

  2. Choose either CLI or file-based configuration

  3. For CLI: Run claude mcp add vitest npx -y @djankies/vitest-mcp

  4. For file: Create .mcp.json with the configuration above

  5. Verify with /mcp command 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.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

Example Configuration

{
  "mcpServers": {
    "vitest": {
      "command": "npx",
      "args": ["-y", "@djankies/vitest-mcp"]
    }
  }
}

Setup Steps

  1. Open Claude Desktop

  2. Navigate to File → Settings → Developer

  3. Click Edit Config

  4. Add the configuration above

  5. Save and restart Claude Desktop

  6. Look for the MCP indicator (🔌) in the conversation input

Configuration Methods

  • Workspace: .vscode/mcp.json in your project

  • Global: Run command MCP: Open User Configuration

Example Configuration

{
  "mcpServers": {
    "vitest": {
      "command": "npx",
      "args": ["-y", "@djankies/vitest-mcp"],
      "type": "stdio"
    }
  }
}

Setup Steps

  1. Install VS Code 1.86+ with GitHub Copilot

  2. Open Command Palette (Cmd/Ctrl + Shift + P)

  3. Run MCP: Add Server

  4. Select Workspace Settings or Global

  5. Add the configuration and save

  6. Access via Copilot Chat: Add Context → MCP Resources

Configuration Location

  • Project: .cursor/mcp.json in your project directory

  • Global: ~/.cursor/mcp.json for all workspaces

Example Configuration

{
  "mcpServers": {
    "vitest": {
      "command": "npx",
      "args": ["-y", "@djankies/vitest-mcp"]
    }
  }
}

Setup Steps

  1. Create the configuration file in your preferred location

  2. Add the server configuration

  3. Restart Cursor

  4. The MCP server will be available in Cursor's AI chat

  5. 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

  1. Open Windsurf Settings (Cmd/Ctrl + ,)

  2. Navigate to Cascade settings

  3. Add MCP server configuration

  4. Reload MCP servers to activate

Configuration via Cline UI

Example Configuration

{
  "mcpServers": {
    "vitest": {
      "command": "npx",
      "args": ["-y", "@djankies/vitest-mcp"]
    }
  }
}

Setup Steps

  1. Open VS Code with Cline extension installed

  2. Click the Cline icon in the sidebar

  3. Click MCP Servers → Configure MCP Servers

  4. Add the vitest-mcp configuration

  5. Save and reload VS Code

  6. 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: 18+ 🟢

  • Vitest: 0.34.0+ 🧪

  • Coverage: @vitest/coverage-v8 (for coverage analysis) 📊

npm install --save-dev vitest@latest @vitest/coverage-v8@latest

🧰 Tools

set_project_root

🚨 Required first - Set the project root for all operations.

Parameter

Type

Required

Description

path

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

directory

string

Yes

Directory to search for test files

run_tests

Execute tests with structured output.

Parameters:

Parameter

Type

Required

Description

target

string

Yes

File or directory to test

format

string

No

Output format: "summary" or "detailed" (auto-detects based on results)

showLogs

boolean

No

Include console output with [stdout] or [stderr] prefixes

project

string

No

Vitest project name for monorepos

analyze_coverage

Analyze test coverage with gap insights.

Parameter

Type

Required

Description

target

string

Yes

File or directory to analyze coverage for

format

string

No

Output format: "summary" (overview only) or "detailed" (includes line-by-line coverage)

exclude

string[]

No

Patterns to exclude from coverage (e.g., ["**/.stories."])

Note: Coverage thresholds should be configured in your vitest.config.ts file, not via MCP parameters.

Automatically excludes test utilities, mocks, stories, and e2e files.

🔄 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.sh

Then 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 test

Or 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

The MCP server automatically detects and uses Vitest configuration files in the following priority order:

  1. vitest.mcp.config.ts - MCP-specific configuration (highest priority) 🔝

  2. vitest.config.ts

  3. vitest.config.js

  4. vitest.config.mjs

  5. vite.config.ts (if it contains test configuration)

  6. vite.config.js (if it contains test configuration)

  7. vite.config.mjs (if it contains test configuration)

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 } from 'vitest/config';

export default defineConfig({
  test: {
    // MCP-specific settings
    reporters: ['json'],
    coverage: {
      enabled: true,
      provider: 'v8',
      reporter: ['json', 'html'],
    },
  },
});

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):

  1. Command-line flags

  2. Environment variables

  3. Configuration file

  4. Built-in defaults

🧑🏻‍💻 Development Mode & Debugging

Enable Debug Mode

Set the debug environment variable for detailed logging:

VITEST_MCP_DEBUG=true

Or 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: npm install --save-dev vitest@latest

"Coverage provider not found" - Install: npm install --save-dev @vitest/coverage-v8@latest 📊

Hook issues - Bypass with: VITEST_HOOK_BYPASS=1 npm test

Found a bug? Submit a bug report, please, and thank you.

📜 License

MIT — See LICENSE.

Available Tools

4 tools
analyze_coverageA

Perform comprehensive test coverage analysis with line-by-line gap identification, actionable insights, and detailed metrics for lines, functions, branches, and statements. Automatically excludes common non-production files (stories, mocks, e2e tests) and provides recommendations for improving coverage. Detects and prevents analysis on test files themselves. Requires set_project_root to be called first. Coverage thresholds are configured via vitest.config.ts.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
targetYesSource file path or directory to analyze coverage for. Should target the actual source code files, NOT test files. Can be a specific source file (e.g., "./src/utils/helper.ts") or directory (e.g., "./src/components"). Relative paths resolved from project root. Required to prevent accidental full project analysis which can be slow and resource-intensive.
formatNoOutput format: "summary" (basic metrics), "detailed" (comprehensive analysis with file details)summary
excludeNoGlob patterns to exclude from coverage analysis. Examples: ["***.test.*", "**/e2emocks/**"]. Useful for excluding test files, stories, mocks, or other non-production code from coverage calculations.

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses automatic exclusion of non-production files, prevention of analysis on test files, and configuration via vitest.config.ts. No annotations exist, so description carries full burden; it adequately informs about safety and no destructive actions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with key information upfront and a dedicated 'USE WHEN' section. Slightly verbose but every sentence adds value; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, description explains what metrics are returned (lines, functions, branches, statements) and provides example patterns for exclude parameter. Covers prerequisites, automatic behaviors, and usage triggers comprehensively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with good descriptions. Description adds context beyond schema: target should be source code (not test files), relative paths from project root, and why target is required (prevents slow full analysis).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it performs test coverage analysis with metrics for lines, functions, branches, and statements, and distinguishes from sibling tools (list_tests, run_tests, set_project_root) by focusing on coverage rather than test execution or listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly lists when to use (coverage-related queries) and states prerequisite 'Requires set_project_root to be called first'. Also recommends preferring this over raw vitest coverage commands. Missing explicit when-not usage, but the guidance is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoOptional directory path to search for test files. Can be relative (e.g., "./src/components") or absolute. If not provided, searches the entire project root. Useful for limiting search scope to specific directories or modules.

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses recursive directory search, pattern filtering, and output of structured file info. Since no annotations are provided, the description carries the full burden, and it adequately conveys read-only exploration behavior without side effects, though it could explicitly state no modifications occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement and a separate usage section. It is concise but not overly terse; every sentence adds value, though the 'USE WHEN' repetition slightly reduces tightness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 optional param, no output schema), the description covers purpose, usage criteria, patterns, and prerequisites. However, it lacks explicit output format details and error handling, which would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one optional parameter 'path' with a comprehensive description covering relative/absolute paths and default behavior. The tool description adds no additional semantic value beyond what the schema already provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool discovers and catalogs test files across the project, supporting patterns like .test.* and .spec.*. It distinguishes from sibling tools like run_tests and analyze_coverage by focusing on exploration rather than execution or analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes explicit 'USE WHEN' guidance, listing specific user queries like 'what tests exist' and contexts. It also states a prerequisite ('Requires set_project_root to be called first'), which helps prevent misuse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 monorepo projects with workspace configuration. 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
targetYesFile path or directory to test. Can be a specific test file (e.g., "./src/components/Button.test.ts") or directory (e.g., "./src/components"). Relative paths are resolved from project root. Required to prevent accidental full project test runs.
formatNoOutput format: "summary" (simple summary data only), "detailed" (structured information about each failing test and summary of passing tests). Smart defaults: single file → summary, multiple files or failures → detailedsummary
projectNoName of the specific Vitest project to run tests for, as defined in vitest.workspace.ts or vitest.config.ts projects array. Essential for monorepos with multiple packages/apps. Example: "client", "api", "shared".
showLogsNoCapture and include console output (console.log, console.error, etc.) from test execution in the results. Useful for debugging test failures. Output is formatted with [stdout] or [stderr] prefixes to distinguish message types.

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses safety guards against full project runs, intelligent format detection, console log capture, and monorepo support. Missing details on side effects or return structure, but sufficient for its use case.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with sections, but slightly lengthy. It front-loads the main purpose and features. Could be trimmed slightly without losing clarity, but remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no output schema, and reasonable complexity, the description covers essential behavior. It mentions output is AI-optimized JSON but lacks explicit structure. Still, it provides enough context for agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds value by explaining smart defaults for format, monorepo context for project, and debugging use for showLogs. It clarifies the required nature of target beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Execute Vitest tests' with specific features like AI-optimized output, format detection, log capture, and safety guards. It distinguishes itself from siblings such as analyze_coverage and list_tests by being the only test execution tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes an explicit 'USE WHEN' section listing scenarios like running tests, checking pass/fail, debugging failures, and hints like 'vitest-mcp:'. It also specifies prerequisite 'set_project_root' and advises preferring this tool over raw commands.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path to the project root directory (must start with / on Unix or drive letter on Windows)

TDQS

A3.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; the description only mentions the prerequisite nature but omits behavior on invalid paths, side effects, or persistence, which is insufficient for a configuration tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, no wasted words, front-loads essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose and prerequisite but lacks return value or error details; still adequate for a simple single-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameter details; description adds prerequisite context but no extra parameter semantics, meeting baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sets the project root directory and must be used before other tools, distinguishing it from sibling analysis/test tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states it must be called before other tools, providing clear usage context, though it lacks when-not or alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 4 tool updates
    • First observedanalyze_coverage
    • First observedlist_tests
    • First observedrun_tests
    • First observedset_project_root
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: analyze_coverage for coverage analysis, list_tests for test discovery, run_tests for test execution, and set_project_root for project setup. The descriptions explicitly differentiate their functions, making misselection unlikely.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., analyze_coverage, list_tests, run_tests, set_project_root). The naming is uniform and predictable, using snake_case throughout without any deviations.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose of Vitest test management. Each tool earns its place by covering essential operations: project setup, test discovery, execution, and coverage analysis, avoiding bloat or thinness.

Completeness4/5

The tool set covers core test workflows (setup, discovery, execution, coverage analysis) effectively, but there are minor gaps such as no tools for test creation, updating, or deletion, which agents might need to work around. However, the provided tools handle the primary use cases well.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Test Analyzer MCP Server

    giri-jeedigunta
    F
    license
    C
    quality
    D
    maintenance
    Enables 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.
    3
    1
    -

  • testmcp

    r-marques
    F
    license
    Not graded
    quality
    D
    maintenance
    Wraps existing test frameworks (Jest, Vitest, Pytest) and exposes structured, LLM-optimized results via MCP tools with progressive disclosure and diff-aware execution.
    1
    -

  • tuxedo-qa

    jonathan-ponciano
    A
    license
    A
    quality
    B
    maintenance
    Enables AI assistants to create, run, autocorrect, and monitor Playwright tests for your app with a local dashboard, credential vault, and public status page.
    16
    MIT

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/djankies/vitest-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server