Skip to main content
Glama

triage_test_coverage

Batch-audit files and directories to identify fragile test coverage, returning a weakest-first ranked leaderboard of mutation scores in one call.

Instructions

Batch triage: audit a set of files and/or directories and return a weakest-first ranked leaderboard of mutation scores, so you can see where the test suite is most fragile in one call. Directories are recursively expanded to supported source files (.ts/.js/.py/.rs/.php), skipping test files. Files are audited in parallel (see fileConcurrency, default min(4, cpus-1)), under a shared wall-clock budget (see totalTimeoutMs). Drill into a weak file with audit_code_resilience for per-mutant survivor detail.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathsNoWorkspace-relative files and/or directories to triage. Directories are recursively expanded to supported source files. Example: ["src/utils", "src/index.ts"]
diffBaseNoAuto-scope the triage to files changed in git. "HEAD" (uncommitted), "staged", or any ref/branch/SHA (merge-base with HEAD). Makes "paths" optional: diffBase alone scans all changed supported source files; diffBase + paths intersects with those paths. TypeScript files are mutated only on changed lines; other languages run whole-file. Example: "main"
maxFilesNoCap on the number of files audited (precedence: this arg > config.defaultMaxFiles > 25). Files beyond the cap are skipped (reported in the summary). Example: 25
minScoreNoGate: if any file's mutation score is below this (0–100), the result reports gate.passed=false and lists the failing files. Never causes an error. Example: 80.
timeoutMsNoPer-file mutation-run timeout in milliseconds. Default: 300000 (5 minutes). Must be <= 2147483647 (the largest delay a timer accepts). Also clamped by whatever remains of totalTimeoutMs.
outputFormatNoOutput format. "json" (default) or "text".
totalTimeoutMsNoWall-clock budget for the WHOLE sweep in milliseconds. Default: 900000 (15 minutes). Files not started before it runs out are returned in "unaudited" rather than audited, so a large sweep still returns the ranking it produced. Must be <= 2147483647 (the largest delay a timer accepts). Example: 1800000
fileConcurrencyNoHow many files to audit in parallel. Default min(4, cpus-1). When >1, each StrykerJS run's worker count is capped, and each mutant's test run is pinned to a single vitest worker, so the three layers multiply out to roughly the core count rather than to fileConcurrency x strykerConcurrency x vitestWorkers. Raise with care on a workstation: a sweep is still the most resource-hungry thing this server does. Example: 4
mutatorDenylistNoStryker mutator names to exclude, applied to every TypeScript/JS file.
survivorsPerFileNoHow many top (severity-ranked, enriched) survivor groups to inline per ranked file. 0 (default) returns a scores-only leaderboard. Example: 3

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
gateNo
modeYes
noteYes
errorsYes
rankingYes
summaryYes
scopeNoteNo
unauditedNo
stoppedReasonNo
Behavior4/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds meaningful behaviors beyond the schema: directories are recursively expanded to supported source files (.ts/.js/.py/.rs/.php), test files are skipped, files are audited in parallel with a default concurrency, and there is a shared wall-clock budget. It does not mention every behavior (e.g., diffBase scoping or gate behavior), but those are covered in the schema, and the description provides a solid behavioral overview.

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?

The description is three sentences, front-loaded with a clear purpose statement. Each sentence adds value: the first states the core function and output, the second explains directory expansion and test-file exclusion, and the third covers parallelism and time budget while pointing to the relevant parameters. No filler or redundancy.

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?

The tool is complex (10 parameters, output schema, no annotations), and the description covers the main purpose, scoping behavior, parallelism, time budget, and points to a sibling for deeper analysis. It does not mention diffBase, minScore, or maxFiles, but these are fully described in the schema. Given the rich structured metadata, the description provides sufficient orientation without being exhaustive.

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%, with each of the 10 parameters having a detailed description, so the baseline is 3. The tool description adds the 'skipping test files' nuance and references fileConcurrency and totalTimeoutMs, but it does not add significant new parameter-level semantics beyond what the schema already provides. It earns the baseline but no higher.

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 opens with 'Batch triage: audit a set of files and/or directories and return a weakest-first ranked leaderboard of mutation scores,' which clearly states the verb (audit), resource (files/directories), and specific output (mutation score leaderboard). It also differentiates from sibling audit_code_resilience by noting 'Drill into a weak file with audit_code_resilience for per-mutant survivor detail,' establishing this tool as the high-level batch overview.

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 explicitly tells when to use this tool ('see where the test suite is most fragile in one call') and names the alternative for deeper detail ('Drill into a weak file with audit_code_resilience'). It also gives context on how scoping works (directories recursively expanded, test files skipped) and key execution parameters (fileConcurrency, totalTimeoutMs), providing clear usage direction.

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

Install Server

Other Tools

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/AraneaDev/Chaos-MCP'

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