Skip to main content
Glama
ppdm-mcp-server

ppdm-mcp-server

by Moodswing9

nw_list_failed_savesets

Identify and list NetWorker savesets that failed to complete successfully, so you can quickly locate backup failures for troubleshooting.

Instructions

List NetWorker savesets that did not complete successfully.

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": "nw_list_failed_savesets"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax results

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.2.2

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are supplied, so the description must carry the full behavioral burden and it does not. It never states that this is a read-only operation, how failures are defined (aborted vs partial vs timed out), whether results are paginated beyond 'limit', or whether historical savesets are included.

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?

A single short sentence with no wasted words, and the distinguishing qualifier ('did not complete successfully') is placed at the end where it reads naturally. It is efficient but perhaps too terse given the absence of annotations.

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 one-parameter read-only list tool with full schema coverage and no output schema, the description is minimally adequate. However, with zero annotations and no output schema, an agent is left guessing about return shape, failure semantics, and safety profile.

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?

There is one optional parameter ('limit') and the schema fully documents it with a default of 20, so schema coverage is 100% and the baseline of 3 applies. The description adds nothing about ordering, truncation, or how to retrieve more than the limit.

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?

The description states a specific verb and resource ('List NetWorker savesets') with a clear scope qualifier ('did not complete successfully'), so an agent knows it is a filtered list of failures. It does not explicitly contrast with the sibling nw_list_savesets, which would be the natural alternative, so differentiation is left implicit.

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 implied by the phrase 'did not complete successfully' – use this instead of a general list when you only want failures. There is no explicit when-to-use/when-not statement or named alternative, and no prerequisites such as authentication or product availability are mentioned.

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