Skip to main content
Glama
jonasliesas

singlestore-mcp-server

by jonasliesas
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

schema_explorer_cleanup_drop

Destructive

Drops selected work tables one at a time for cleanup, re-checking each, refusing system databases, and handling dependent views. Use dry_run to preview DROP TABLE IF EXISTS statements with no changes.

Instructions

Drop the selected work tables one statement at a time (DROP TABLE IF EXISTS), for the Clean-up panel.

Re-checks each table on the server; system databases are refused and a table
with a dependent view is skipped unless that view is listed in ``views``
(it is then dropped first). With ``dry_run`` only the statements are returned.

Args:
    tables: [{"database": "SASDP", "name": "_dmallchars"}, ...]
    views: Dependent views to drop as well, same shape.
    dry_run: Only show the statements; drop nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewsNo
tablesYes
dry_runNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.1

TDQS

A4/5.0
Behavior5/5

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

Annotations already flag it as destructive, and the description adds substantive behavior beyond them: server-side re-checks, refusal of system databases, dependent-view skipping unless the view is passed in 'views', and dry_run returning statements only. This is exactly the kind of safety disclosure an agent needs before a destructive call.

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?

Front-loaded with the drop action and constraint behavior, then an Args block. Every sentence contributes; only minor redundancy in restating the panel context.

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, 3-param tool with no output schema, the description covers action, guardrails, params, and dry-run behavior. The return format of the non-dry-run path is not described, but that is a minor gap given the annotations carry the safety profile.

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 description coverage is 0%, so the description carries the param burden and does so well: 'tables' and 'views' get an example shape ({"database": "SASDP", "name": "_dmallchars"}) and 'dry_run' is explained. It omits that dry_run defaults to true, which the schema supplies, keeping it just short of 5.

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?

States a specific verb and resource ('Drop the selected work tables ... for the Clean-up panel') with an implementation detail (one DROP TABLE IF EXISTS per table). An agent can tell what it does, though it does not explicitly differentiate itself from siblings like cleanup_work_tables or schema_explorer_cleanup_scan.

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 'Clean-up panel' framing and the dry_run mode imply when it is used, and the view-handling rule implies prerequisites, but there is no explicit when-to-use/when-not or named alternative. Usage is inferable rather than stated.

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