reqtrace-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_requirementsB | List requirements with their current verification status. |
| get_requirementB | One requirement with its implementing code, linked tests, latest results, coverage, review state and number of open issues. |
| trace_matrixB | Full trace matrix: requirement -> code -> tests -> latest results, plus code that no requirement asked for and annotations that name unknown requirements. |
| find_gapsC | Everything standing between this repo and verified, signed-off requirements, each
with a suggested next action. |
| impact_of_changeA | Requirements and tests affected by changes since |
| run_verificationA | Run the repo's tests under coverage and map results to requirements. Python:
pytest with per-test contexts. C/C++: builds with clang coverage (and MC/DC) using the
build commands in .reqtrace.yaml, then runs each test in its own process. With
|
| coverage_reportB | Statement and branch coverage (plus MC/DC for C/C++ with clang >= 18) of each requirement's implementing code from the latest run, with uncovered lines, branches and conditions, and implementing code that no linked test executes. |
| lint_requirementsA | Deterministic requirement quality checks (missing acceptance criteria, vague words, compound requirements). Judging ambiguity and conflicts is your job: use flag_requirement_issue. |
| flag_requirement_issueA | Record a problem with a requirement for a human to resolve. Use this instead of guessing when a requirement is ambiguous, conflicts with another, or can't be tested. |
| propose_linksB | Suggest trace links you believe exist but are not annotated. They are stored as UNCONFIRMED and do not count until a human accepts them. Prefer adding annotations. |
| record_reviewA | Ask a HUMAN to sign off requirements. The human is prompted for their name and rationale; you cannot supply them. If no human answers, nothing is recorded. |
| evidence_reportA | Write the evidence pack (Markdown + matrix JSON) to .reqtrace/evidence/ for a human to review. Run run_verification first so results are current. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| implement_traceably | Implement one requirement with full traceability and evidence. |
| independent_review | Independent verification review of requirements (comma-separated ids). |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| requirements_resource | All requirements as JSON. |
| matrix_resource | The current trace matrix as JSON. |
| evidence_resource | The evidence report, rendered from current state. |
TDQS
Scored across 12 tools
Most tools target distinct actions: get_requirement vs list_requirements (one vs all), run_verification vs coverage_report (execution vs metrics), find_gaps vs lint_requirements (blocking gaps vs quality checks). There is mild overlap between trace_matrix, coverage_report, and get_requirement since all surface mapping/coverage data, but the descriptions give enough framing to distinguish them.
All names use consistent snake_case with a mostly verb_noun pattern (get_requirement, list_requirements, run_verification, lint_requirements, flag_requirement_issue, propose_links, record_review). A few are noun phrases (trace_matrix, coverage_report, evidence_report, impact_of_change), which is a minor deviation but still predictable and readable.
Twelve tools sit squarely in the well-scoped range for a requirements-traceability and verification server. Each tool maps to a distinct lifecycle activity (inspect, verify, report, flag, propose, sign off), so no tool feels redundant or missing.
The surface covers the full traceability loop: listing/getting requirements, running verification, coverage, gap detection, quality linting, issue flagging, link proposals, human sign-off, and evidence export. The only gap is no direct tool to author or edit requirements, but this appears intentional given the annotation-based, human-in-the-loop design.