test-inventory-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | The project folder, passed with --root <dir>. Optional; defaults to CLAUDE_PROJECT_DIR or the folder the client starts the server in. | |
| patterns | No | The globs of the test files, relative to the project, passed as positional arguments to test-inventory-mcp (e.g. "tests/**/*.spec.ts"). Optional; tool calls can pass other patterns. | |
| framework | No | The test framework for the globs, passed with --framework: either "playwright" or "vitest". Optional. | |
| CLAUDE_PROJECT_DIR | No | The project folder named by Claude Code, used when --root is not given. |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| test_summaryA | Counts a project's tests by state (active, skip, fixme, todo, expectedToFail, notLoaded) and by tag and annotation, from the test files, without running them. Use it first, for questions such as how many tests are skipped, or which files or tags have the most skipped tests; use find_tests to list the tests themselves. states, tags and grep count only the tests they match. groupBy "file" or "tag" adds the counts of each file or tag, sorted by name and paged with limit and cursor; a test with no tag is in no tag group. Example: {"states": ["skip", "fixme"], "groupBy": "file"}. |
| find_testsA | Lists a project's tests that match filters, read from the test files without running them: each with its id, full name, file and line, state, skip reason and condition, and tags by default. Use it for questions such as which tests are skipped and why, which tests carry @smoke, or where a .only was left in; use test_summary for counts and get_tests for every key of a few ids. Filters combine with AND; a list matches any of its values. fields picks other keys of the test records (id is always there). Answers are paged: follow nextCursor, or narrow the filters. Example: {"states": ["skip"], "withoutReason": true}. |
| get_testsA | Returns every key of the tests with the given ids, with the scan diagnostics about them, read from the test files without running them: location, describe path, state and where it is set, condition, reason, tags, annotations, comments above the test, parameters and body hash. Use it after find_tests or test_summary, for the details of up to 20 tests. Ids come from find_tests and stay the same when a test moves to another line, but change when its title, describe or file changes; ids not in the current scan are returned in notFound. Example: {"ids": ["3f9a0c1d2e4b5a69"]}. |
| scan_diagnosticsA | Lists the problems test-inventory found while reading the test files: level error means tests may be missing from the other answers (a file that failed to parse, an import it could not follow), level warning means a value is missing or approximate (a title built at run time, a tag that is not a string). They are about reading the code, not test failures. Use it when another tool reports scanErrors, or to check why a test is missing or notLoaded. Answers are paged: follow nextCursor. Example: {"levels": ["error"]}. |
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 4 tools
Each tool has a clearly distinct role: test_summary for aggregate counts, find_tests for filtered lists, get_tests for full details on specific ids, and scan_diagnostics for parsing problems. The descriptions explicitly cross-reference each other ('use test_summary for counts', 'use find_tests to list the tests themselves'), leaving no ambiguity about which tool to pick.
Three tools follow a clean verb_noun pattern (find_tests, get_tests, scan_diagnostics), making intent predictable. test_summary deviates by being noun-first, a minor inconsistency but still readable and unambiguous.
Four tools is well-scoped for a read-only test inventory server, with each tool covering a distinct access pattern (aggregate, list, detail, diagnostics). It is slightly lean but nothing is missing that an agent would need.
The surface covers the lifecycle of inspection well: summarize, list, drill into details, and surface scan errors, all without running tests as intended. Minor gaps exist (no direct tag/file enumeration), but find_tests and test_summary with groupBy make these workarounds available.