Skip to main content
Glama
jonasliesas

singlestore-mcp-server

by jonasliesas

workload_define

Idempotent

Create or replace a saved test workload (it can then be run with workload_run, again and again).

Instructions

Create or replace a saved test workload (it can then be run with workload_run, again and again).

Args:
    name: Workload name (letters, digits, spaces, . - _).
    statements: [{"sql": "...", "per_minute": 30, "name": "Top makes", "database": null, "id": "s1",
        "enabled": true}]. per_minute is how often the statement runs (with pacing "max": its relative
        weight). SQL may use placeholders filled per execution: {{int:1:1000}}, {{float:0:1}},
        {{pick:a|b|c}}, {{date:2024-01-01:2024-12-31}} (quote strings yourself: '{{pick:US|EU}}').
    database: Default database for the statements.
    pacing: "rate" (each statement per_minute times a minute) or "max" (as fast as the connections can).
    concurrency: Connections (parallel workers), 1-64.
    duration_s: How long a run lasts, 5 s - 4 h.
    timeout_s: Per-statement timeout; the statement is cancelled (KILL QUERY) after it.
    arrivals: "even" (fixed spacing) or "random" (Poisson arrivals at the same average rate).
    think_ms: Pause between statements per worker (pacing "max").
    fetch_rows: Read every result row (off measures just the execute time, not the time to read rows back).
    allow_writes: Allow statements other than SELECT / WITH (they run repeatedly: use a test table).
    trace_all: Turn on full query tracing on the cluster for the run, so every statement (not just those
        over the trace threshold) shows up in Query History afterwards. Affects the whole cluster.
    original_name: The workload's current name when renaming it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
pacingNorate
arrivalsNoeven
databaseNo
think_msNo
timeout_sNo
trace_allNo
duration_sNo
fetch_rowsNo
statementsYes
concurrencyNo
descriptionNo
allow_writesNo
original_nameNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.0

TDQS

A4.3/5.0
Behavior5/5

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

Going well beyond the annotations, the description discloses rich runtime behavior: timeout_s triggers a KILL QUERY, allow_writes means statements run repeatedly (warning to use a test table), trace_all affects the whole cluster, fetch_rows toggles whether row read-back time is measured, and arrivals/pacing govern traffic shape. These are exactly the operational consequences an agent needs before calling a test-execution tool.

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?

A one-line purpose is front-loaded, followed by compact per-argument glosses with the most consequential flags (allow_writes, trace_all) carrying explicit caveats. It is dense but every line is justified by a 14-parameter, zero-coverage schema; slight trimming of the placeholder examples could tighten it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter, zero-schema-coverage tool with annotations already covering the safety profile and an output schema available, the description supplies the pacing model, limits, side effects, and SQL placeholder dialect an agent needs to call it correctly. Nothing material is missing except the trivial 'description' field.

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 carries the full burden and mostly succeeds: it gives value ranges (concurrency 1-64, duration 5s-4h), pace semantics, placeholder syntax for SQL ({{int:...}}, {{pick:a|b|c}}, quoting strings), statement object shape, and the renaming role of original_name. Only the 'description' parameter is left undocumented, a minor omission against 13 well-specified params.

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 opening states a specific verb+resource ('Create or replace a saved test workload') and names the follow-up tool (workload_run). It does not, however, distinguish this from near-siblings like workload_save or workload_from_history, so an agent still has to infer which definition entry point to pick.

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 implied through the workflow hint that the workload 'can then be run with workload_run, again and again' and via locating tests here ('saved test workload'). There are no explicit when-not conditions or comparisons against workload_save / workload_from_history, which also create or persist workloads.

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