Loading ToolBench
A Test Receipt Printer for git. Every CI run prints a receipt to .taf — append-only, timestamped, cannot be gamed. Proof over time.
This MCP server has significant definition quality gaps. While tool names follow verb_noun conventions reasonably well (parseTestOutput, updateTafFile, generateBadge, runTafGit, switchToTargetBranch, commitTafUpdate), the descriptions are inconsistent in quality and depth. Several tools lack parameter descriptions entirely. Input schemas are present but minimal, most parameters lack detailed type constraints, enums, or format specifications. No output schemas are documented. Error handling is largely absent from tool definitions. The server is a STDIO-only transport, which further limits practical utility for remote agents. Descriptions range from adequate (parseTestOutput: 173 chars) to extremely minimal (several tools under 100 chars). Many parameter descriptions are vague or missing entirely (e.g., the 'logger' function parameter in runTafGit has no description).
Commit .taf file changes to git and push to remote.
Generate a badge SVG from a .taf file. Returns shields.io-style SVG badges from .taf test history.
Parse Bun test output to extract test results. Anchored on 'Ran <N> tests across <M> files.' summary line.
Parse Jest output to extract test results. Handles formats like 'Tests: 1 failed, 172 passed, 173 total'
Parse test output from any supported framework: the first parser in PARSERS that recognises the output wins. Supports Bun, WJTTC, Jest, and Vitest.
Parse Vitest output to extract test results. Handles formats like ' Tests 8 passed (8)' or ' Tests 2 failed | 6 passed (8)'
Parse WJTTC (pc-ai bar) output to TestResults. Supports both human log format and machine JSON format.
STDIO-only transport: server is not remotely accessible and cannot work with hosted MCP clients
Output schemas completely undocumented: LLMs cannot infer what fields are returned by tools (e.g., parseTestOutput returns TestResults with 'total', 'passed', 'failed', 'skipped', 'result' fields, but this is not declared in the tool definition)
runTafGit has a 'logger' function parameter with NO description or type guidance, LLMs cannot determine what signature this function should have or when to supply it
updateTafFile 'testResults' parameter lacks detailed schema, no field definitions for the expected object structure (must contain 'total', 'passed', 'failed', 'skipped', 'result', but LLM has no visibility into these fields)
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Main CLI function - reads test output from file and updates .taf receipt with test results.
Switch to a dedicated target branch for TAF receipts. Creates the branch as an orphan on first run, seeded with existing .taf.
Update .taf file with new test results. Creates the file if it doesn't exist.
No error handling guidance in any tool definition, LLMs have no context on what errors are retryable, how to recover from missing files, or what to do when git operations fail
Parse tools (parseJestOutput, parseBunOutput, parseVitestOutput, parseWjttcOutput) lack parameter constraints, 'output' is just a raw string with no format or length guidance
generateBadge has optional parameters 'tafPath' and 'label' with defaults, but descriptions do not explain the default behavior or consequences if omitted
runTafGit parameters 'commitMessage' and 'cwd' lack validation constraints, no guidance on path format, message length, or special character handling
switchToTargetBranch and commitTafUpdate both execute git commands but no tool description documents that these have side effects (git state changes, branch creation, pushes) or permission requirements