Skip to main content
Glama
Sign In
covera-mcp

covera-mcp

Official
by SuresoftTechnologies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Start a recovery case

covera_recovery_start

Starts recovery by copying an analysis-error ZIP/folder or downloading the latest from the COVER server into a new run directory, recording initial evidence and state without changing originals.

Instructions

Copy the analysis-error ZIP/folder (or collect the latest from the server) into a new run directory and record initial evidence and state. Does not modify original sources. May download from the COVER server, which needs COVER_ACCESS_KEY or cached credentials.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "source": "<source>",
      "runDir": "<runDir>"
    },
    "name": "covera_recovery_start"
  }
}

Input Schema

NameRequiredDescriptionDefault
runDirYesAbsolute path of the new run directory to create (required).
serverNoCOVER server root URL for this recovery.
sourceYesSource identifier of the analysis error (required).
agentRootNoAbsolute path of the COVER EE Local Agent install folder, if it should override the environment.
artifactsNoAbsolute path of error material; omit to auto-find from the build context.
verifyTlsNoVerify the HTTPS certificate and hostname. Omitted, TLS verification is skipped (the default on internal COVER servers with self-signed certificates).
hardwareIdNoBuild Agent HardwareID; omit to read it from the build account file.
serverRootNoAbsolute path of a local COVER server install folder or catalina.home.
projectRootNoAbsolute path of the build working directory where the analysis-error command ran.
searchRootsNoExtra folders or ZIP files to search; repeatable.
hardwareFileNoAbsolute path of the build account's HardwareID file.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Adds real context beyond the annotations: it creates a new run directory (consistent with readOnlyHint=false), explicitly guarantees original sources are untouched (reinforcing destructiveHint=false), and discloses that server downloads require COVER_ACCESS_KEY or cached credentials. What is missing is failure behavior — e.g. what happens if runDir already exists, which matters given idempotentHint=false.

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

Conciseness4/5

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

Two compact sentences with the core action front-loaded and the non-destructiveness guarantee plus auth caveat trailing usefully. Slightly dense parenthetical constructions, but no sentence is filler.

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

Completeness4/5

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

For a write-ish, open-world tool with 11 parameters and no output schema, the description covers purpose, filesystem effect, source-preservation, and credential needs. Remaining gaps are what the call returns (run directory path, case handle) and preconditions on runDir, which an agent would need before invoking.

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

Parameters3/5

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

Schema description coverage is 100%, so all 11 parameters are already documented; baseline 3 applies. The description adds only indirect meaning, tying the server-download path to credential requirements, without clarifying source, artifacts, or searchRoots beyond the schema.

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

Purpose4/5

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

States a specific verb and resource: copy the analysis-error ZIP/folder or collect the latest from the server into a new run directory and record initial evidence/state. An agent can tell this is the case-creation step, though the 'or collect the latest from the server' clause blurs the line with the sibling covera_recovery_collect, which is not named or contrasted.

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

Usage Guidelines3/5

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

Usage is only implied: the name and 'new run directory' framing suggest it is the first step of a recovery workflow. There is no explicit when-to-use or when-not-to-use guidance, and no routing to siblings such as covera_recovery_collect or covera_recovery_discover, even though the collection overlap is real.

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

Deploy Server

Other Tools