Skip to main content
Glama

Công cụ MONA app delete

cloud_app_delete
DestructiveIdempotent

Delete an approved cloud app and remove its domain and A record; app host billing may continue. Use sandbox to test deletion without real infrastructure or charges.

Instructions

App từ git đã live: app host đầu tiên ~2–3 phút, deploy sau đó 10–20 giây. / Git apps are live. Sau khi user duyệt xoá: xoá app/domain/A record; app host vẫn có thể tính phí. / Delete an approved app.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
app_idYes
sandboxNoThử 0đ, không tạo hạ tầng thật / Sandbox, no charge

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.0

TDQS

B3.2/5.0
Behavior4/5

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

The annotations already cover destructiveHint, idempotentHint, and openWorldHint, so the safety profile is known. The description adds meaningful context beyond that: it specifies that app, domain, and A record are deleted, and warns that the app host may still incur charges. The unrelated first sentence about git app liveness adds noise but does not contradict the tool's behavior.

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

Conciseness2/5

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

The definition is not front-loaded: it opens with an unrelated sentence about git app deploy timing before stating the actual delete operation. That sentence is waste and pushes the core purpose into the middle of a bilingual, slash-separated block, reducing clarity and conciseness.

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?

For a destructive delete tool with no output schema, the description does convey the cascade of deletions and a billing caveat, which are important. However, it omits parameter detail for app_id and its leading sentence is irrelevant, so the definition is only partially complete given the tool's complexity.

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

Parameters2/5

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

Schema description coverage is 50%: sandbox is documented in the schema, but app_id has no description there. The tool description does not compensate by explaining what app_id represents or its format, only referring to 'an approved app'. This leaves the required parameter under-specified.

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 description states a specific verb and resource: 'Delete an approved app.' That is clear enough for an agent to identify the operation. However, it gives no explicit differentiation from the duplicate sibling vibecloud_app_delete, and the leading sentence about git app deploy timing is irrelevant and dilutes focus.

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?

The phrase 'Sau khi user duyệt xoá' implies a prerequisite of user approval before deletion, which gives some usage context. It does not name alternatives or state when not to use this tool, so guidance is only implied.

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