Charming

delete_app

Destructive

Permanently delete a Charming app the caller owns, optionally also purging its stored data. Use this to remove an app the caller no longer wants. Deletion is irreversible and requires confirmation: the host is asked to show a confirmation prompt, and when it cannot, the call fails closed until re-invoked with confirm: true.

Input Schema

TableJSON Schema

Name	Required	Description
`app_id`	Yes	The app ID (UUID) to delete
`confirm`	No	Explicit confirmation that the caller intends to permanently delete this app. Fallback for hosts that cannot show a confirmation prompt: set true only after the deletion has been confirmed with the user through another channel. On hosts that do support a prompt, the prompt is authoritative and this field is ignored.
`purge_storage`	No	Also delete stored app data

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	UUID of the targeted app.
`ok`	Yes	Indicates success. Errors arrive as content with isError:true.
`deleted`	Yes	True if the app was deleted, false if deletion was cancelled by the user.
`cancelled`	No	Set to true when the user declined the elicitation confirmation prompt.
`advisories`	No	Structured non-fatal advisories, including authoring issues and unread staff feedback responses. Each advisory.summary is also appended to the text content for the LLM path.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 10, 2026

addedOutput schema / properties / advisories

Added value: +{
+  "description": "Structured non-fatal advisories, including authoring issues and unread staff feedback responses. Each advisory.summary is also appended to the text content for the LLM path.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "data": {
+        "additionalProperties": {},
+        "description": "Kind-specific structured payload. Shape varies per advisory kind.",
+        "propertyNames": {
+          "type": "string"
+        },
+        "type": "object"
+      },
+      "doc_url": {
+        "description": "Optional docs pointer for this advisory kind.",
+        "type": "string"
+      },
+      "kind": {
+        "description": "Stable advisory identifier (e.g. \"legacy-bridge\").",
+        "type": "string"
+      },
+      "severity": {
+        "description": "Severity; omitted advisories are treated as 'info'.",
+        "enum": [
+          "info",
+          "warn"
+        ],
+        "type": "string"
+      },
+      "summary": {
+        "description": "Agent-facing summary. Self-sufficient; no extra context required.",
+        "type": "string"
+      },
+      "userSummary": {
+        "description": "End-user-facing summary. Set when the advisory should render in-app.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "summary"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

First observedJul 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the destructiveHint annotation by spelling out irreversibility, the host-side confirmation prompt, and the fail-closed behavior that requires confirm: true when the prompt is unavailable. This gives the agent a complete picture of side effects and safeguards.

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 tight sentences, front-loaded with the core action, then the conditional nuance. No redundant filler; every clause carries information.

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?

Covers the action, ownership constraint, optional data purge, irreversibility, and confirmation edge-case behavior. With a full input schema and clear sibling distinctions, nothing essential is missing for an agent to invoke it correctly.

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?

Input schema already covers all three parameters at 100% coverage; the description adds real value for confirm by explaining the fail-closed fallback semantics. It does not deepen app_id or purge_storage much beyond the schema, but the confirm addition justifies a strong score.

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?

The description opens with a specific verb and resource ('Permanently delete a Charming app the caller owns'), adds the optional purge-storage nuance, and clearly distinguishes this from siblings like update_app or delete_routine. No ambiguity about what the tool does.

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?

'Use this to remove an app the caller no longer wants' gives a clear call-context, and the ownership condition further scopes when it applies. It does not explicitly name alternatives or say when not to use it, so it falls short of a full 5.

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

All Charming tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.