Handsome Hosting

List backups

list_backups

Read-only

The backup points on the server of a live WordPress site, newest first: stamp, time, kind (scheduled nightly, manual, pre-restore, pre-import) and the size of the database and files halves; a restore takes the stamp. older counts the points kept off the server, which the person brings back on the website first (olderNote). running names a backup or restore under way; nextManualAt is when a manual backup opens again.

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": {
      "serviceId": "<serviceId>"
    },
    "name": "list_backups"
  }
}

Input Schema

Name	Required	Description	Default
`serviceId`	Yes	the id of a service on this account

Output Schema

Name	Required	Description	Default
`ok`	Yes
`data`	No
`error`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

changedInput schema / properties / serviceId / description

Previous value: -"the service id from list_services"New value: +"the id of a service on this account"

First observedOct 23, 2026

TDQS

A3.7/5.0

Behavior4/5

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

The readOnlyHint=true annotation already establishes the safety profile, and the description usefully adds ordering behavior ('newest first'), field meanings, off-server backup semantics ('older'), in-progress status ('running'), and the manual-backup reopening time ('nextManualAt'). It does not cover auth, rate limits, or error behavior, but it adds meaningful behavioral context beyond the annotations.

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 description is compact and front-loads the resource being returned, but it is a single dense semicolon-separated sentence without an explicit action verb at the start. It avoids waste, though the structure could better separate core purpose from result-field semantics.

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 one required parameter, full schema coverage, read-only annotations, and an output schema, the definition is largely complete. It adds useful semantics for special fields like older, running, and nextManualAt, though it does not address prerequisites such as the service needing to be a live WordPress site.

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 only one parameter (serviceId), and schema description coverage is 100%, so the schema already documents it as 'the id of a service on this account.' The description does not add further parameter detail, which is acceptable given the schema coverage but does not earn above baseline.

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 clearly identifies the resource and scope: backup points on the server of a live WordPress site, newest first, with named fields such as stamp, time, kind, and size. It is specific enough for an agent to recognize this as a read/list-style operation, but it never explicitly names or contrasts with siblings such as backup_now or rollback.

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 rather than stated: the description explains that a restore takes the stamp and that older backup points must be brought back on the website first. These details help an agent interpret results and plan a restore, but the description does not explicitly say when to choose this tool over backup_now, rollback, or action_status.

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

All Handsome Hosting tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?