Skip to main content
Glama
Sign In
sandraschi

opencode-cli-mcp

by sandraschi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

OpenCode Backups

opencode_backups
Destructive

Backup the opencode database and config with rotation + disk guard; restore when needed.

Instructions

Backup the opencode database and config with rotation + disk guard; restore when needed.

Return Format

{"success": bool, "message": str, "data": dict}

Examples

opencode_backups(action="status") opencode_backups(action="create", kind="all") opencode_backups(action="list", kind="db") opencode_backups(action="restore", name="opencode-db-20260802-120000.sqlite3", confirm=True)

Input Schema

NameRequiredDescriptionDefault
kindNoTarget: database, config directory, or both (create/prune)all
nameNoBackup filename (required for restore/delete)
forceNoAllow restore while opencode serve is running
actionYesstatus: paths, free space, counts, last backup. create: take a snapshot of the database (kind=db), config (kind=config), or both (kind=all). list: backups with sizes/dates. prune: drop old backups beyond retention. restore: overwrite the database or config from a backup (confirm=True; refuses while opencode serve is running unless force=True). delete: remove one backup file.
confirmNoMust be True for restore (overwrites live data)

Output Schema

NameRequiredDescriptionDefault
dataYes
messageYes
successYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.2.11
    • removedOutput schema / additionalProperties
      Removed value: -true
    • addedOutput schema / properties
      Added value: +{
+  "data": {
+    "type": "object"
+  },
+  "message": {
+    "type": "string"
+  },
+  "success": {
+    "type": "boolean"
+  }
+}
    • addedOutput schema / required
      Added value: +[
+  "success",
+  "message",
+  "data"
+]
  2. First observedv0.2.3

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the schema enumerates the confirm/force guards and the 'refuses while opencode serve is running' rule. The description adds only the phrases 'rotation + disk guard', which hint at retention and free-space checks without explaining either. Nothing contradicts the annotations, but little is added beyond them.

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

Conciseness3/5

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

The purpose sentence is front-loaded and tight. However, the '## Return Format' block restates a return shape that the output schema already defines, and the examples duplicate enum values already in the schema, so a portion of the text does not earn its place.

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?

An output schema exists, so the description needn't explain return values (and its return-format block is therefore redundant). It also leaves the destructive restore/delete paths to the schema rather than warning about overwriting live data in prose. Adequate, but with avoidable gaps for a destructive 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 description coverage is 100%, including detailed per-action semantics and confirm/force rules, so the baseline is 3. The description's examples illustrate action/kind/name/confirm combinations but add no syntax or constraint information the schema lacks.

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 opening sentence names a specific resource (opencode database and config) and the two primary verbs (backup, restore), plus differentiating traits (rotation, disk guard). It doesn't cover the other four actions (status, list, prune, delete), which are only discoverable from the schema enum. No sibling does backups, so differentiation is not a concern.

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?

'restore when needed' is the only usage hint and it is essentially tautological. The examples show call shapes for status/create/list/restore but give no conditions for choosing prune over delete, or when to check status first. Usage is implied by the action examples rather than stated.

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