io.github.phoenice-labs/universal-test-framework
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| UTF_PROJECT_DIR | No | The project directory to use for registry isolation. If not provided, falls back to the current working directory. |
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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generate_testsA | Generate a complete test suite satisfying the 8-section test contract. The framework automatically:
|
| validate_test_contractA | Validate a test or test suite against the 8-section contract. Use this to check any existing test — generated or hand-written — for compliance. The contract requires all 8 sections: Test ID, Why Generated, Requirement Mapping, How it Exercises, Coverage Contribution, Expected Outcome, Gaps, Meaningfulness Check. |
| analyze_coverageC | Analyze the coverage of a test suite and identify gaps. |
| build_traceability_matrixB | Build a requirements-to-tests traceability matrix. |
| suggest_test_typesB | Analyze code/requirements and suggest which test types to apply. |
| detect_language_frameworkB | Detect programming language and test framework from source code. |
| healthA | Health check for the Universal Test Framework MCP server. Returns server status, version, and uptime. Suitable for use as a Docker HEALTHCHECK command, Kubernetes liveness/readiness probe, or basic availability verification. Returns: status : "ok" when the server is healthy version : UTF semantic version string uptime_s : seconds the server process has been running tools : number of registered MCP tools |
| query_registryB | Query the UTF persistent test registry. |
| run_testsC | Execute test files and return structured results with CI annotations. Execution is always optional — controlled by UTF config. Never blocks generation. |
| run_mutation_testsA | Run mutation testing on a source+test file pair and return coverage metrics. Supports mutmut (Python), Stryker (JS/TS), PIT (Java), and gremlins (Go). The adapter is auto-detected based on language and tool availability. |
| feedback_statusA | Get UTF feedback loop status: gap analysis, coverage health, trend, and delta requirements. |
| import_test_resultsA | Import JUnit XML execution results into the UTF registry. Use this when you have already run tests with pytest / Maven / Go and want to register the results so that generate_report shows real pass/fail rates. |
| generate_reportA | Generate the 8-section contract compliance report (Tool #12). Reads test records and execution results from the registry, builds the contract report in the requested formats, and returns report paths + summary. |
| register_contractsA | Parse test files and register per-method 8-section contract records. This is the UTF registration bridge — it reads LLM-written test files, extracts the per-method 8-section comment blocks, and upserts status=generated rows into the UTF registry. Without this step, generate_report has no Per-Test Contract Detail cards. IMPORTANT — Phase 1, Step ③ of the UTF 3-phase workflow: ① generate_tests (scaffold) ② Write real test methods with per-method TC-{PRJ}-{MODULE}-{NNN} blocks ③ register_contracts ← this tool ④ generate_report (verify contract detail cards) ⑤ pytest --junit-xml=... ⑥ import_test_results ⑦ generate_report (now shows both contract cards AND execution results) |
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 14 tools
Most tools have distinct purposes, but analyze_coverage and feedback_status both address coverage gaps, causing slight ambiguity. Overall, the majority are clearly distinguishable.
Nearly all tools follow a consistent verb_noun snake_case pattern (e.g., generate_tests, run_mutation_tests). Only health deviates slightly but is still clear.
With 14 tools, the surface covers all necessary operations for a test framework server without being excessive. Each tool serves a well-defined role.
The tool set covers the entire workflow from test generation, validation, registry, execution, mutation testing, reporting, and import. No obvious gaps for the intended domain.