Skip to main content
Glama
Sign In
singlestore-mcp-server

singlestore-mcp-server

by jonasliesas
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

schema_explorer_reshard_script

Read-only

Generates a DBA-ready SQL script to change a table’s shard key: builds a replacement table, copies data, checks row count and skew, and swaps tables.

Instructions

"Change shard key…": a SQL script for a DBA (nothing runs). CREATE TABLE __reshard from the real SHOW CREATE TABLE with only the SHARD KEY replaced, INSERT … SELECT, a row-count and skew check, the rename swap and a commented-out DROP of the old table, with warnings filled in for this table (size, pipelines, views, grants, duration). Read-only (logic and docs in ..reshard).

Args:
    database: Database (case-sensitive).
    table: Table (case-sensitive).
    columns: The new shard key's columns, as the table spells them.
    simulation: The simulation result's numbers (rsd_pct, current_rsd_pct, elapsed_ms, fraction,
        partition_count) for the header and the duration estimate; optional.

Input Schema

NameRequiredDescriptionDefault
tableYes
columnsYes
databaseYes
simulationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.11.0

TDQS

A4/5.0
Behavior4/5

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

readOnlyHint=true is consistent with 'nothing runs', so no contradiction. Beyond annotations, the description discloses the exact script anatomy, that the DROP of the old table is commented out (a meaningful safety detail), that warnings are pre-filled for this table (size, pipelines, views, grants, duration), and that the duration estimate depends on the simulation numbers — real behavioral context the annotation does not carry.

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?

The main paragraph is front-loaded and dense with useful content, and the Args block is compact. Minor friction: the opening `""Change shard key…":` doubled quote is awkward and the first sentence packs a long list, but nothing is filler.

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?

With no output schema, the description correctly explains what is returned (the script's parts and its embedded warnings), and it covers all four inputs plus the no-execution guarantee. What is missing is minor: ordering relative to the simulation tool and whether the caller needs SHOW CREATE TABLE / grant visibility for the warnings to be populated.

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

Parameters5/5

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

Schema coverage is 0%, so the description must carry the parameter burden and it does: `database` and `table` are flagged case-sensitive, `columns` must be 'as the table spells them', and `simulation` is described as optional with its constituent keys enumerated (rsd_pct, current_rsd_pct, elapsed_ms, fraction, partition_count) along with what they feed. This adds meaning far beyond the bare property names and titles.

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 artifact — a resharding SQL script containing CREATE TABLE, INSERT … SELECT, a skew check, and a rename swap — and clarifies that 'nothing runs', which separates it from execution-oriented siblings. It implicitly points at schema_explorer_reshard via the `simulation` argument ('the simulation result's numbers') but never names that sibling explicitly, so the routing cue is weaker than it could be.

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?

Usage is only implied: the audience ('for a DBA') and the `simulation` parameter suggest this is the follow-up step after a simulation run, but the description never says 'call this after schema_explorer_reshard' or states any preconditions. It does say 'Read-only (logic and docs in ``..reshard``)', which is a weak pointer to the related module rather than a when-to-use rule.

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