dvera-mcp
DVERA — CT Verification Skills for C/C++ Coding Agents
한국어: README.ko.md
DVERA (Dynamic Verification Agent) brings CT C/C++ verification work into coding agents such as Claude Code, Codex CLI, Cursor, and GitHub Copilot. It uses the working context of source code, requirements, build information, source changes, and existing test assets to prepare and request CT verification work.
CT (Controller Tester) is a test automation solution for unit, integration, and code-based testing of mission-critical C/C++ software. It brings together test-environment setup, test design and generation, execution, code-coverage analysis, reporting, and traceability management.
DVERA does not replace CT's verification results. The coding agent helps prepare and coordinate verification work; CT performs the analysis, build, test execution, and result aggregation. Generated tests must be reviewed for test intent, data, and expected results, then confirmed with actual execution results and measured coverage.
What the CT and DVERA workflow adds
Verification need | CT and DVERA workflow |
Complex C/C++ environments | Capture compiler, macro, include-path, toolchain, build, and target conditions before analysis. |
Unit and integration verification | Design and execute tests at function, module, and interface levels, including existing GoogleTest assets where applicable. |
Reviewable evidence | Connect test intent, execution results, statement/branch/MC/DC coverage, reports, and requirement links for review. |
Repeated change verification | Re-run affected tests after code changes and review new failures and coverage deltas for regression follow-up. |
AI-assisted test work | Use code, requirements, and change context to prepare test work, then improve it with CT analysis and measured results. |
Related MCP server: clangd-mcp
Workflow at a glance
Prepare the compiler, macro, include-path, toolchain, and target context for a CT project.
Analyze the project and resolve environment or configuration issues through a controlled feedback loop.
Generate, execute, and improve unit or integration tests using build, execution, and coverage feedback.
Review coverage and results, produce reports, and re-run affected verification after source changes.
The Skills in this repository document that product-connected workflow. They are not standalone replacements for a CT installation.
Install
In Claude Code:
/plugin marketplace add SuresoftTechnologies/dvera-plugin
/plugin install dvera@suresofttechOr from a terminal:
claude plugin marketplace add SuresoftTechnologies/dvera-plugin
claude plugin install dvera@suresofttechSkills then load as /dvera:ct-init-project, /dvera:ct-test-loop, and so on. The plugin adds about 620 tokens to every session; each Skill body is read only when that Skill runs.
Product-backed actions need a deployed CT environment. Without one, a Skill stops at its installation check and shows how to reach product support.
Example requests
Trigger examples from the CT user guide. Responses can vary with the AI model and conversation context; if the result differs from what you expect, rephrase the request with more detail and retry.
Request | Skill |
|
|
|
|
|
|
|
|
|
|
|
|
Skills
All Skills require a deployed CT environment for their product-backed actions and stop with an installation notice when none is found.
Skill | CT workflow stage |
| Start or prepare a CT verification project. |
| Capture target compiler macros and build-environment facts. |
| Prepare the analysis configuration for the selected toolchain. |
| Create the CT project and apply build inputs. |
| Analyze the project and resolve configuration or toolchain issues. |
| Generate, run, and improve tests. |
| Record verified workflow observations after a completed CT run. |
| Re-run existing tests after a code change and review deltas. |
| Run regression evidence collection and identify CT Self-Healing review candidates. |
| Re-run GoogleTest assets registered in CT and review results and coverage. |
| Generate and execute a CT AI test from approved requirements. |
| Export execution and coverage evidence. |
| Open the CT project for visual inspection. |
| Resume the appropriate stage of an in-progress verification workflow. |
Product-backed workflow
DVERA works with a deployed CT and DVERA environment. This repository documents the verification workflow and ships an MCP server that forwards tool calls to a local CT installation, but does not include the CT runtime or product installation.
Without the deployed environment, users can inspect this repository's documented workflow, but a Skill that needs CT actions stops at its installation check. It must not claim that CT analysis, execution, coverage measurement, or reporting has occurred.
MCP tools
Give the agent CT's verification tools directly. With the MCP server
(scripts/dvera-mcp.py) connected, it can create the project, run analysis, generate and
execute tests, and read coverage back without leaving the conversation - the same tools CT
exposes to its own agent. Calls go to CT's ct_tool.py entry point, and the server keeps no
process of its own between them.
Connect it in one of two ways.
Point an MCP client at the interpreter CT already ships - no extra install:
{
"mcpServers": {
"dvera": {
"command": "C:/Program Files/Suresoft/CT 2026/python/python.exe",
"args": ["/path/to/dvera-plugin/scripts/dvera-mcp.py"]
}
}
}On Linux the interpreter is at <CT install>/python/python3. Any Python 3.8 or later works
if you would rather use your own. Replace the script path with wherever this repository
sits: clone it, or use the copy the plugin manager installed (claude plugin list shows
where plugins live). The server takes the source directory from the client's working
directory, so run the client from the project you want to verify.
Or install the bundle from this repository's releases: download dvera-mcp.mcpb and
open it with a client that installs MCP bundles. It resolves its own Python, so nothing has
to be installed first.
Set CT_HOME if CT is installed outside the default location. The server is safe to leave
configured on any machine: it starts either way, and without CT it offers a single tool,
dvera_check_environment, which reports what is missing and what to do about it. That tool
is also there when CT is - run it first whenever the verification tools do not appear.
Requirements for product-backed verification
CT 2026.06 or later
A valid CT license
A supported C/C++ build and target environment
DVERA integration supplied as part of the deployed CT environment
For a product demo, purchase, or deployment consultation, contact bizcenter@suresofttech.com.
Privacy Policy
The MCP server in this repository runs entirely on your machine.
It sends nothing to Suresoft Technologies or to any third party. There is no telemetry, no analytics, and no network call of its own.
Tool arguments are passed to the CT installation on the same machine, and CT's response is returned to your MCP client. Nothing is written outside CT's own workspace.
It stores no credentials and reads no files beyond the CT installation directory and the paths a tool call names.
Anything CT itself records - workspaces, analysis output, reports - is governed by CT's own handling of that data, not by this repository.
The Skills are documentation: they carry no code that runs on your machine.
The full policy is in PRIVACY.md. Questions about data handling in the CT product itself go to bizcenter@suresofttech.com.
License and trademarks
This repository is licensed under the MIT License. The license covers everything in this repository - the documentation, the Skill files, and the MCP server source. It does not cover CT itself: CT and DVERA are Suresoft Technologies products, and no product functionality or product licence is granted by this repository.
GoogleTest is a trademark of Google LLC. This repository is not affiliated with, sponsored by, or endorsed by Google. Other product names may be trademarks of their respective owners.
Available Tools
1 tooldvera_check_environmentCheck DVERA environmentARead-only
Report whether a local CT installation is usable by DVERA, and what is missing when it is not. Takes no arguments and needs no CT install, so it is the tool to run when the verification tools are absent from the list.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true is present, and the description does not contradict it. The description adds context about what the tool reports (usability and missing components), which is useful beyond the annotation. However, it does not detail the format of the report (e.g., whether it returns a list of missing items, a boolean, or a message). Since annotations only cover the read-only nature, a 3 is appropriate – it adds some behavioral context but not exhaustive detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, and front-loads the core purpose. The first sentence states the report action and what it covers, the second provides usage guidance. No wasted words. A small deduction because it could be slightly more structured (e.g., bullet points for missing items), but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema, no siblings), the description covers the essential information: what it does, when to use it, and prerequisites. It could delve into the output format, but given the lack of an output schema, a brief note on what 'report' entails would enhance completeness. Nevertheless, it is largely sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema reflects that. The description reinforces that it 'takes no arguments,' which adds explicit clarity beyond the empty schema. Even though schema coverage is 100% (trivially), the description's explicit statement makes this a good example; a baseline of 4 is justified for no-param tools as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to report on the usability of a local CT installation for DVERA, including what is missing. It uses specific verbs ('Report', 'check') and names the resource ('local CT installation', 'DVERA'). It also distinguishes itself by noting it is the tool to run when verification tools are absent, which helps with sibling differentiation (though no siblings are listed).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'the tool to run when the verification tools are absent from the list.' It also clarifies that it takes no arguments and needs no CT install, setting clear usage context. There is no direct mention of alternatives, but given the absence of siblings, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Added
dvera_check_environment
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion or overlap with other tools.
The single tool name follows a clear verb_noun pattern (dvera_check_environment), though with only one tool the pattern is not strongly established.
A single tool is extremely thin for a server; even if the purpose is narrow, one tool provides very limited functionality.
The tool only checks the environment; there are no tools to actually perform DVERA operations, so the surface is severely incomplete for any real workflow.
Maintenance
Related MCP Connectors
An MCP server that provides access to Testiny projects, test cases and test runs
Scans remote MCP servers for protocol, security, and TLS issues; exposes scan tools via MCP.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
MCP server exposing the Backtest360 engine API as tools for AI agents.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceMCP server for AI DevTool workflow, exposing tools and resources for code review, repository chat, and repository operations.1-
- AlicenseAqualityDmaintenanceMCP server for C/C++ code analysis using clangd and clang tools, providing diagnostics, symbol search, include analysis, function listing, and code formatting.5MIT
- AlicenseNot gradedqualityBmaintenanceEnables aggregation, filtering, transformation, and composition of tools from multiple MCP servers through a single proxy with tool views.5AGPL 3.0
- FlicenseNot gradedqualityBmaintenanceAggregates MCP tools from AT series IDE plugins into a single server, routing calls to plugin bridges for SSH, JumpServer, and more.1-