Skip to main content
Glama

Databases Drop Database

databases_drop_database
Destructive

Drops a Snowflake database after confirmation, enabling removal of unneeded databases.

Instructions

Drop a database in Snowflake. Requires confirmation flag.

Input Schema

NameRequiredDescriptionDefault
nameYesQuote names that aren't all uppercase, exactly as list tools return them.
confirmNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.0.0
    • addedInput schema / properties / name / description
      Added value: +"Quote names that aren't all uppercase, exactly as list tools return them."
  2. Addedv2.0.4

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, so the safety profile is known without the text. The description adds one genuinely new behavioral fact — that the call is gated behind a confirmation flag — but does not state irreversibility, what dependent objects are lost, or that recovery via undrop is possible.

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

Conciseness4/5

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

Two short sentences, front-loaded with the action and immediately followed by the guard condition; no filler. It is efficient, though the brevity edges toward under-specification for a destructive operation.

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?

An output schema exists and annotations carry the destructive profile, so return-value explanation is not needed. However, for a permanent, irreversible Snowflake drop, the description omits the consequences (cascading loss of schemas/tables) and the undrop recovery path, which an agent should know before calling.

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 50%: the 'name' parameter is well documented including quoting rules, but 'confirm' has no schema description beyond a default of false. The sentence 'Requires confirmation flag' fills exactly that gap by conveying the flag must be set to true, adding real meaning beyond the structured 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?

The description names a specific verb and resource — 'Drop a database in Snowflake' — which is unambiguous. It does not differentiate from the closely related siblings databases_undrop_database or databases_create_database, so an agent must infer the distinction from the names alone.

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?

'Requires confirmation flag' establishes a precondition for invocation, which is the strongest usage signal present. There is no guidance on when to prefer this over alternatives (e.g., undrop for recovery) or when not to use it, leaving usage largely 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