Skip to main content
Glama
Sign In
Vitest MCP Server

Vitest MCP Server

by djankies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

run_tests

Execute targeted Vitest tests and return AI-friendly structured JSON results, with optional console logs and safeguards to prevent accidental full project runs.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
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
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.
projectNoName of the specific Vitest project to run tests for, as defined in the `projects` array of vitest.config (or vitest.workspace on Vitest 3). 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.0
    • changedInput schema / properties / project / description
      Previous value: -"Name 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\"."New value: +"Name of the specific Vitest project to run tests for, as defined in the `projects` array of vitest.config (or vitest.workspace on Vitest 3). Essential for monorepos with multiple packages/apps. Example: \"client\", \"api\", \"shared\"."
  2. First observed

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 the full behavioral burden and does so well: it discloses structured JSON output, automatic format detection, opt-in console capture, monorepo support via Vitest projects, and a safety guard preventing full-project runs. It stops short of describing error/exit behavior or how the safety guard manifests, which keeps it from a 5.

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?

Two paragraphs, capability summary first and usage triggers second, with no filler. The opening sentence is a dense feature list but remains scannable and front-loaded.

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?

For a tool with no output schema and no annotations, the description covers purpose, prerequisite ordering, output shape, and invocation triggers. Minor gaps remain around failure/exit reporting, but nothing an agent needs to call it correctly is absent.

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%, so the baseline is 3. The description still adds meaning by tying the required target to the safety guard ('prevent full project runs') and by explaining that project selection exists for monorepos, giving rationale the schema alone does not.

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 opening sentence names a specific verb and resource (execute Vitest tests) and immediately characterizes the output style and guardrails. An agent can distinguish this from list_tests and analyze_coverage because this is the only tool that actually executes the suite.

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?

An explicit 'USE WHEN' block enumerates the triggering intents (run tests, check pass/fail, debug failures) and literal keywords ('test', 'vitest', 'vitest-mcp:'). It also states the prerequisite that set_project_root must be called first and recommends this over raw vitest commands.

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

Deploy Server

Other Tools