Skip to main content
Glama
Sign In
covera-mcp

covera-mcp

Official
by SuresoftTechnologies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Survey a recovery (read-only)

covera_recovery_discover
Read-only

Inspect build environment, COVER server settings, and available analysis-error material read-only, then report missing items needed to collect recovery data.

Instructions

Read the build environment, COVER server settings, and available analysis-error material without changing anything, and report what is missing to collect it. Read-only.

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>"
    },
    "name": "covera_recovery_discover"
  }
}

Input Schema

NameRequiredDescriptionDefault
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.
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

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description mostly restates that safety profile ('without changing anything', 'Read-only'). It does add one piece of behavior beyond annotations — that it produces a report of missing material needed for collection — but says nothing about how that report is shaped, how long a scan takes, or what network access openWorldHint implies.

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?

The core sentence is front-loaded and dense with useful scope information. The trailing fragment 'Read-only.' is redundant with both the earlier 'without changing anything' and the readOnlyHint annotation, a small but real piece of waste.

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

Completeness3/5

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

For a 9-parameter, no-output-schema tool, the description covers the intent adequately but not the result: since no output schema exists, the description should sketch what the 'missing material' report contains. It also does not clarify how this survey relates to the collect/verify siblings in the recovery workflow.

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% across all 9 parameters, so the schema already explains server, source, agentRoot, verifyTls, hardwareId, and the root paths. The description adds no parameter-level meaning such as precedence between serverRoot and server or how searchRoots interacts with projectRoot, so baseline 3 applies.

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 concrete verb (read/survey) and concrete resources (build environment, COVER server settings, analysis-error material), plus the outcome of reporting what is missing. It is distinguishable from siblings like covera_recovery_collect because it explicitly frames itself as the diagnostic precursor to collecting, though it never names a sibling.

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 through the phrase 'report what is missing to collect it', which suggests running this before collection. There is no explicit when-to-use statement, no exclusion, and no named alternative among covera_recovery_inspect or covera_recovery_collect, leaving the agent to infer ordering.

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