Skip to main content
Glama

Delete the app

delete_app
Destructive

Permanently deletes a live app and its database, files, and secrets. Provide the exact app name to confirm; this action cannot be undone.

Instructions

Deletes the live app with its database, files and secrets. It cannot be undone. Only call this when the person asked for it, and pass the app name (from teamonly.json) as "confirm".

Input Schema

NameRequiredDescriptionDefault
confirmYesThe app name, to confirm
directoryNoAbsolute path of the app's folder (the one with teamonly.json). Defaults to the folder the server started in.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare destructiveHint and openWorldHint, yet the description adds high-value specifics: exactly what gets destroyed (database, files, secrets), that it is irreversible, and that human intent must be confirmed first. That is real disclosure beyond the annotation flags.

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 short sentences, each carrying distinct load: consequence, irreversibility, invocation gate. The blast-radius statement is front-loaded where an agent will see it first.

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?

For a destructive two-param tool with no output schema, the description covers consequence, irreversibility, and the confirmation contract. It does not state what happens if the app is absent or how the directory parameter interacts with app resolution, but those are minor gaps.

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?

Schema coverage is 100%, so baseline is 3, but the description adds a semantic constraint the schema omits: the confirm value must be the app name sourced from teamonly.json. That turns a generic string param into a verified identity check.

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?

States a specific verb and resource ('Deletes the live app') and immediately scopes the blast radius ('with its database, files and secrets'). No sibling tool competes with this operation, and the destructive scope is unmistakable.

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?

Gives an explicit precondition — 'Only call this when the person asked for it' — plus how to satisfy the confirmation parameter. No alternatives are named, but among the siblings none performs a delete, so there is little to disambiguate against.

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