Skip to main content
Glama

install_purge

Destructive

Permanently stops and removes an installed app, deleting containers, config, and volumes without creating a backup; use only when data loss is intended.

Instructions

Stop an installed app and delete all data including containers, config, and volumes. Nothing here restores it and no backup is taken first: take one before calling if the data matters. A volume that still exists afterwards (external, or used by another container) is listed in kept_volumes, and one Docker could not be asked about in unchecked_volumes

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": {
      "app": "<app>"
    },
    "name": "install_purge"
  }
}

Input Schema

NameRequiredDescriptionDefault
appYesApp name

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.2

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already mark this as destructive, but the description adds irreversibility, the fact that no backup is taken automatically, and post-call volume reporting via kept_volumes and unchecked_volumes. This goes well beyond structured annotations.

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?

Front-loads the destructive action and immediately follows with the irreversible consequence and backup warning. Three tight sentences, and the kept_volumes/unchecked_volumes caveat also earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation with no output schema, it covers data loss, backup requirements, and partial return behavior. Together with the destructive annotation, an agent has enough context to call it safely.

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 required parameter, app, and schema coverage is 100% with 'App name'. The description refers to an 'installed app' but adds no syntax or format semantics beyond the schema.

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 action—stop and delete all data including containers, config, and volumes—for an installed app. It is clearly destructive and more complete than a generic uninstall, though it does not explicitly name install_uninstall as the non-destructive sibling.

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?

Provides an explicit prerequisite: take a backup before calling if the data matters. It does not explicitly contrast install_uninstall or give a when-not-to-use condition beyond the data-loss warning.

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