vunit-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VUNIT_MCP_PYTHON | No | interpreter that runs run.py (must have vunit-hdl + a simulator; the default has both) | |
| VUNIT_MCP_TIMEOUT | No | max seconds per run/compile | 600 |
| VUNIT_MCP_SIMULATOR | No | passed through as VUNIT_SIMULATOR | VUnit auto-detect |
| VUNIT_MCP_EXTRA_ARGS | No | extra run.py args (escape hatch) | |
| VUNIT_MCP_OUTPUT_DIR | No | default -o output path | <project>/vunit_out |
| VUNIT_MCP_RUN_SCRIPT | No | run script path relative to project dir | run.py |
| VUNIT_MCP_PROJECT_DIR | Yes | dir containing run.py (required by all tools) | |
| VUNIT_MCP_FINGERPRINT_EXCLUDE | No | comma-separated patterns (fnmatch globs on file name or project-relative path, or a directory name) of registered files whose content changes must not invalidate the export cache — for generated/volatile files; adding or removing them still does |
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vunit_statusA | Report server configuration: project dir, run script, interpreter, VUnit version, and whether a simulator appears available. Call this first when diagnosing setup problems. |
| vunit_list_testsA | List all test cases (lib.entity[.proc]) the project knows about. Does not require a simulator. |
| vunit_list_filesA | List all source files in compile order. Does not require a simulator. |
| vunit_compileA | Compile all sources in the VUnit project (--compile). Requires a simulator. Safe to re-run. |
| vunit_run_testsA | Run VUnit tests and return a pass/fail summary plus the list of failing tests. Patterns default to ['*'] (run everything). A JUnit XML is always written next to the output dir for vunit_get_report. Requires a simulator. |
| vunit_get_reportA | Re-read the last run's JUnit report from the output dir (no re-run). Returns per-test status, with the number of failing VUnit checks per test when its log shows any. Pass a failing test name to vunit_get_test_log to see why it failed. |
| vunit_get_test_logA | Get the log output for one test (the per-test output.txt), which is
how you see WHY a test failed. test_name is the full name from
vunit_list_tests / vunit_get_report. Returns the last 100 lines by
default (failure info appears at the end); pass a larger |
| vunit_export_jsonA | Export the project model (source files, all tests, attributes) as JSON via --export-json. Attributes carry requirement/traceability data. The export is cached at .vunit-mcp-cache/export.json in the project and re-run only when the project's sources change. Does not require a simulator. |
| vunit_test_dependenciesA | Return the ordered list of source files needed to implement one test case: the files it depends on to elaborate, grouped by library in compile order (VUnit built-in files summarized as a count). Does not compile and needs no simulator. |
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 9 tools
Each tool targets a distinct concern: configuration health, test listing, file listing, compilation, running, report retrieval, per-test logs, JSON export, and dependency resolution. There is no meaningful overlap even between get_report and get_test_log because one is the aggregate results summary and the other is the raw output for a single test.
All tools share the vunit_ prefix and mostly follow a verb_noun pattern (list_tests, list_files, run_tests, get_report, get_test_log, export_json). Minor deviations like vunit_status and vunit_compile are still readable and do not create confusion.
Nine tools is well-scoped for a VUnit test project workflow. Each tool covers a distinct step from inspection and compilation through running tests and debugging failures, and none feels redundant or extraneous.
The tool set covers the full practical VUnit workflow: diagnosing setup, discovering tests and files, compiling, running, retrieving aggregate results, inspecting per-test logs, exporting project data, and tracing test dependencies. There are no obvious dead ends that would prevent an agent from completing a typical build-and-debug cycle.