Skip to main content
Glama
krovacloud

@krovacloud/mcp

Official

List Backups

list_backups
Read-only

List a space's backups newest first, including Cube disk and configuration copies redeployable as new Cubes. Requires View Backups permission.

Instructions

List the space's backups, newest first: each is a Cube's disk and configuration kept after the Cube is gone, redeployable as a new Cube. sharedFromBackupId is set on a copy another space shared with this one. Needs the View Backups permission.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
spaceIdNoKrova Cloud Space id. Optional if KROVA_SPACE_ID is set as the server default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.12

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds valuable context: newest-first ordering, that backups persist after the Cube is gone and are redeployable, and that sharedFromBackupId signals a copy shared from another space. It also states the required permission.

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?

Three compact sentences with zero waste. The purpose and ordering are front-loaded, followed by clarifying semantics and the permission requirement.

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?

With no output schema, the description does a good job explaining what each backup represents and the ordering. It does not mention pagination or response shape, which is a minor gap for a list tool.

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 coverage is 100% and the single optional parameter (spaceId) is fully documented in the schema. The description adds no extra meaning about the parameter itself, so baseline 3 is appropriate.

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 (List) and resource (backups) scoped to the space, plus ordering. Defines what a backup is, making the tool's output semantics clear. Does not explicitly differentiate from siblings like get_backup or list_backup_shares, so only 4.

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?

The permission prerequisite is stated, which helps usage. However, there is no explicit when-to-use vs alternatives guidance—no mention of when to use get_backup, share_backup, or list_backup_shares instead. Usage is only implied by the listing scope.

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