test-inventory-mcp

Overview Schema Source Related Servers Discussions Admin

Scan diagnostics

scan_diagnostics

Read-onlyIdempotent

Lists parse, import, and value problems found while reading test files, explaining missing or notLoaded tests. Use when another tool reports scanErrors or to inspect error and warning diagnostics.

Instructions

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"]}.

Input Schema

TableJSON Schema

Name	Required	Description
`path`	No	Keeps problems in this file, or in the files under this folder, relative to `directory`.
`codes`	No	Keeps problems with these codes.
`limit`	No	The most items to return.
`cursor`	No	nextCursor from the previous answer, for the next page. Keep the other arguments the same.
`levels`	No	Keeps problems of these levels.
`patterns`	No	Globs of the test files, relative to `directory`, such as ["tests/*/.spec.ts"]. Default: the ones the server was started with.
`directory`	No	A folder inside the project to scan, relative to its root, such as "packages/web". Default: the root.
`framework`	No	The test runner. Default: the one the server was started with.

Output Schema

TableJSON Schema

Name	Required	Description
`hint`	Yes
`total`	Yes	All matching items, on every page.
`framework`	Yes
`nextCursor`	Yes
`diagnostics`	Yes	One page of problems, in file order.
`frameworkVersion`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 21, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description still adds real behavioral context beyond that: the semantic difference between error and warning levels, concrete causes for each, and the fact that answers are paged via nextCursor.

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?

Front-loads the core definition before diving into level semantics, then usage, then paging, then an example. Dense but every sentence carries information; length is justified for a tool with two enum levels the agent must interpret.

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?

With annotations covering safety and an output schema covering return shape, the description needn't explain results. It competently covers purpose, triggers, level semantics, and paging, though it says nothing about how the path/patterns/directory/framework parameters interact, which an agent might occasionally need.

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 description coverage is 100% and the 8 parameters are well documented inline, so the baseline is 3. The description's example ({'levels': ['error']}) and its 'follow nextCursor' note restate what the schema already specifies for levels/cursor, adding marginal value only.

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?

States a specific verb and resource ('Lists the problems test-inventory found while reading the test files') and explicitly demarcates scope versus siblings: 'They are about reading the code, not test failures.' An agent can tell this apart from test_summary/find_tests/get_tests without opening any schema.

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?

Gives explicit triggering conditions tied to sibling outputs: 'Use it when another tool reports scanErrors, or to check why a test is missing or notLoaded.' It also disambiguates the common confusion (reading problems vs test failures), leaving little to inference.

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

Deploy Server