covera-mcp

Official

by SuresoftTechnologies

Overview Schema Source Related Servers Discussions Admin

Python

Local

Run a COVER coverage build

covera_coverage_build

Destructive

Plan and run instrumented COVER EE coverage builds for C/C++, C#, or Java projects while preserving original output paths; optionally execute them and register the coverage module.

Instructions

Drive a COVER EE coverage build for a C/C++, C#, or Java project: identify the original build and real tools, plan the instrumented build keeping the original output paths, and -- when execute is true -- run it and keep the successful setup for later builds. Give projectDir to start a new build or jobContext to resume one (exactly one). execute runs the real builds and registers the coverage module on the COVER server, so it changes the project's build setup and server state: read covera_get_guide topic=build first, explain what it does, and get the user's approval before calling with execute. With execute omitted it only plans and writes job state. The result is a workflow envelope; a WAITING_* status means resume with its jobContext after supplying what it asks for. The Open API Access Key is read from the Local Agent's cached credentials or COVER_ACCESS_KEY; this server never prompts for it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "covera_coverage_build"
  }
}

Input Schema

Name	Required	Description
`execute`	No	Run the validated original and coverage builds after planning. Without it, plan only.
`targets`	No	Native GCC build target; repeatable.
`decision`	No	Absolute path of an integrity-protected decision file produced by this runner.
`failFast`	No	Stop on the first coverage build failure; do not run the project-file fallback.
`jobsRoot`	No	Absolute path of the jobs root directory.
`parallel`	No	Build parallelism (default: host CPU count).
`artifacts`	No	Expected build artifact; repeatable.
`serverUrl`	No	Local Agent remote-service URL; defaults to CODESCROLL_TM_SERVER_URL.
`verifyTls`	No	Verify the HTTPS certificate for a new COVER job (skipped by default).
`jobContext`	No	Absolute path of an existing job.json to resume.
`projectDir`	No	Absolute path of the project to build (start a new workflow).
`vsRealTools`	No	Fallback cl.exe/link.exe/lib.exe as TOOL=PATH; repeatable.
`gccBuildTool`	No	Explicit cmake or make executable.
`gccGenerator`	No	CMake generator.
`gccCleanTarget`	No	Clean target name (default: clean).
`gccCoverConfig`	No	COVER config filename under <agent-root>/conf (default: gcc.config).
`gccConfiguration`	No	Build configuration.
`gccConfigureArgs`	No	Extra configure argument; repeatable.
`openApiServerUrl`	No	COVER Open API main web server URL (e.g. https://cover.example.com:4009); required for a new build unless already cached.
`gccBuildDirectory`	No	GCC build directory.
`noEnvironmentProfile`	No	Do not read a previous job's environment profile.
`stm32cubeideExecutable`	No	Explicit stm32cubeidec.exe / stm32cubeide for headless builds.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, it states that execute changes the project's build setup and server state, registers the coverage module, and requires user approval. It also discloses plan-only behavior, WAITING_* resume handling, and the credential source, which is substantial behavioral context for a destructive open-world operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded: purpose first, then parameter and mode rules, the destructive execute warning, resume behavior, and credential handling. Every sentence contributes operational guidance with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 22-parameter destructive tool with no output schema, it covers the critical prerequisites, state changes, approval requirement, plan-only path, resume status handling, and auth source. This is complete enough for an agent to decide whether and how to invoke it safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents all parameters at 100% coverage, so the baseline is 3, but the description adds meaningful constraints such as exactly one of projectDir or jobContext and the execute-versus-plan distinction. It does not add meaning for most of the other parameters, leaving that to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Drive a COVER EE coverage build') and narrows the supported project types to C/C++, C#, and Java. It also distinguishes its planning and execution modes, so an agent can identify the operation without relying on the tool name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete mode-selection guidance: exactly one of projectDir or jobContext, and execute to run real builds versus omitting it to plan only. It also requires reading covera_get_guide topic=build and getting user approval before execute, though it does not explicitly compare this tool with other coverage-related siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server