Skip to main content
Glama

restore_backup

Restore a Minecraft world from backup by replacing the current world with a saved version. Creates a safety backup of the current world before restoration. Requires server to be stopped first.

Instructions

Restore a world from a backup. Creates a safety backup of the current world before overwriting. The server MUST be stopped first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
backup_nameYesBackup name (with or without .tar.gz extension)
confirmYesMust be true to confirm restoration

Implementation Reference

  • The restoreBackup method handles the logic of verifying the backup, creating a safety backup of the existing world folder, and extracting the selected backup.
    /** Restore a world from backup */
    restoreBackup(backupName: string): string {
      const tarName = backupName.endsWith(".tar.gz")
        ? backupName
        : `${backupName}.tar.gz`;
      const backupPath = path.join(this.backupDir, tarName);
    
      if (!fs.existsSync(backupPath)) {
        throw new Error(`Backup not found: ${backupPath}`);
      }
    
      // Extract the world name
      const baseName = tarName.replace(".tar.gz", "");
      const underscoreIdx = baseName.indexOf("_");
      const worldName =
        underscoreIdx > 0 ? baseName.substring(0, underscoreIdx) : baseName;
      const worldPath = path.join(this.serverDir, worldName);
    
      // Remove existing world if present
      if (fs.existsSync(worldPath)) {
        // Create a safety backup before overwriting
        const safetyName = `${worldName}_pre-restore_${Date.now()}`;
        const safetyPath = path.join(this.backupDir, `${safetyName}.tar.gz`);
        execSync(
          `tar -czf "${safetyPath}" -C "${this.serverDir}" "${worldName}"`,
          { timeout: 300000 }
        );
        fs.rmSync(worldPath, { recursive: true, force: true });
      }
    
      // Extract backup
      execSync(`tar -xzf "${backupPath}" -C "${this.serverDir}"`, {
        timeout: 300000,
      });
    
      return `World "${worldName}" restored from backup "${backupName}". The server must be restarted if it was running.`;
    }
  • The restore_backup tool is registered here, including input validation via Zod and calling the BackupManager's restoreBackup method.
    server.tool(
      "restore_backup",
      "Restore a world from a backup. Creates a safety backup of the current world before overwriting. The server MUST be stopped first.",
      {
        backup_name: z
          .string()
          .describe("Backup name (with or without .tar.gz extension)"),
        confirm: z.boolean().describe("Must be true to confirm restoration"),
      },
      async ({ backup_name, confirm }) => {
        if (!confirm) {
          return {
            content: [
              {
                type: "text",
                text: "Restore cancelled. Set confirm=true to proceed.",
              },
            ],
          };
        }
    
        if (manager.isRunning()) {
          return {
            content: [
              {
                type: "text",
                text: "Cannot restore while the server is running. Stop the server first.",
              },
            ],
            isError: true,
          };
        }
    
        try {
          const result = backupManager.restoreBackup(backup_name);
          return { content: [{ type: "text", text: result }] };
        } catch (error) {
          return {
            content: [
              {
                type: "text",
                text: `Restore failed: ${error instanceof Error ? error.message : String(error)}`,
              },
            ],
            isError: true,
          };
        }
      }
    );
Behavior4/5

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

With no annotations provided, description carries full disclosure burden. It successfully reveals: (1) destructive overwrite behavior, (2) automatic safety backup creation as mitigation, and (3) hard prerequisite of stopped server. Missing minor details like safety backup naming convention or post-restore steps.

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 sentences with zero waste: purpose declaration, safety behavior disclosure, and prerequisite warning. Information is front-loaded and every sentence earns its place. Appropriate density for a destructive operation tool.

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?

Given 100% schema coverage and no output schema, description adequately covers the critical safety behaviors and prerequisites for this complex destructive operation. Minor gap: does not indicate success indicators or whether server restart is needed after restoration.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 100% schema coverage (baseline 3), description adds semantic value by contextualizing why 'confirm' parameter exists—it's a destructive overwrite operation requiring explicit confirmation, and why 'backup_name' matters—it triggers the safety backup workflow before the destructive action.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description opens with specific verb 'Restore' + resource 'world from a backup', clearly distinguishing from siblings like create_backup, delete_backup, or list_backups. The additional clause about 'safety backup' and 'overwriting' further clarifies the scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states critical prerequisite 'The server MUST be stopped first', establishing when the tool can be used. Implies when not to use (while server running), though it does not explicitly name the sibling stop_server tool as the required precursor.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tamo2918/Minecraft-Server-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server