Skip to main content
Glama
Sign In
aapanel-mcp

aapanel-mcp

by devochkaskustikom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Delete a database

db_delete
Destructive

Move a database to the panel recycle bin by id and name. Confirm the destructive action with db_delete_check first.

Instructions

Delete a database. The panel moves it to the recycle bin rather than dropping it immediately, but treat it as destructive and confirm with db_delete_check first.

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": {
      "id": "<id>",
      "name": "<name>"
    },
    "name": "db_delete"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesDatabase id from db_list.
nameYesDatabase name, for confirmation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1-alpha.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds a genuinely useful nuance beyond them: the panel moves the database to the recycle bin rather than dropping it immediately, yet the agent should still treat the action as destructive. This corrects a naive assumption about recoverability and is not derivable from the annotations alone.

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?

Two tightly packed sentences: purpose first, then the recycle-bin behavior, then the confirmation prerequisite. No filler, and the destructive warning is front-loaded where an agent will act on it.

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 mutation tool with rich annotations and a fully described schema, the description covers the essentials an agent needs: it is destructive, it is recoverable via the recycle bin, and db_delete_check should precede it. It does not mention permission requirements or what happens to related users/backups, a minor gap.

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?

Schema description coverage is 100%, with both 'id' (from db_list) and 'name' (for confirmation) documented in the schema itself. The description adds no parameter-level detail, so the baseline 3 is appropriate.

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?

Starts with a specific verb+resource ('Delete a database') and immediately distinguishes its behavior from a hard drop, referencing the sibling db_delete_check. An agent can separate this from db_delete_check or db_recycle_bin without opening a schema.

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 the prerequisite sequence: confirm with db_delete_check first before calling this tool. That is clear routing guidance, though it frames db_delete_check as a required precondition rather than spelling out when this tool should not be used.

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