Shows every pipeline's state, source, latest batch and recent errors, with
buttons to start, stop and test pipelines and an auto-refresh. Use this
when the user wants to see or manage pipelines visually.

The result includes ``browser_url``, which opens this view full-window in
the user's browser: post it as a clickable link right under the app.

Args:
    database: Limit to one database. Omit to show pipelines in all databases.

Use this when the user wants to see, browse, sort, filter or export
(CSV) query results, or when a result is too large to read as text. The
user can also edit and re-run the query from the grid. You receive only
a summary with the first 20 rows; the user sees all fetched rows.

Only read-only statements are accepted: SELECT, WITH, SHOW, DESCRIBE,
DESC, EXPLAIN (one statement, no SELECT ... INTO). For writes, DDL or when
you just need a value for your own reasoning, use run_sql instead.

The result includes ``browser_url``, which opens this view full-window in
the user's browser: post it as a clickable link right under the app.

Args:
    sql: A single read-only statement.
    database: Database to run it against (defaults to the connection's
        configured database).
    max_rows: Maximum rows to fetch, 1-10000 (default 1000). The result
        is flagged as truncated when more rows exist.

Shows every database and its tables/views with storage type
(columnstore/rowstore/reference), row counts and sizes; for a selected
table it shows columns, shard key and sort key, the full CREATE TABLE DDL
and a 50-row data preview. The user can browse freely and ask follow-up
questions from the UI. Use this when the user wants to explore, browse or
understand the schema visually. For a plain list of tables or columns
inside your own reasoning, list_tables / describe_table are cheaper.

The result includes ``browser_url``, which opens this view full-window in
the user's browser: post it as a clickable link right under the app.

Args:
    database: Pre-select this database (case-sensitive). Omit to start at the database list.
    table: Pre-select this table or view in `database` (case-sensitive). Requires `database`.

Args:
    database: Database (case-sensitive).
    table: One table (case-sensitive); omit for every table of the database.

SAS jobs leave work tables behind in SingleStore (SAS Data Management
``_dm…`` tables, SAS flow ``_flw…`` tables, ``SASTMP…`` / ``_tmp…``). The
panel scans every non-system database by name pattern (editable, and
optionally every table older than N days) and shows per table its rows,
size, creator, age, last use in the query history and dependent views.
The user selects tables, confirms, and they are dropped one by one (with a
dry-run mode and a log). Nothing is dropped by this call; only the user
can drop from the panel. Use this when the user wants to find or clean up
leftover, temporary or SAS work tables.

The result includes ``browser_url``, which opens this view full-window in
the user's browser: post it as a clickable link right under the app.

Args:
    patterns: [{"pattern": "_dm*", "kind": "SAS DM"}, ...]; shell-style, case-insensitive. Omit for the saved ones.
    older_than_days: Also offer every table not created/altered for this many days.
    recent_days: Tables used or created this recently are flagged as risky.
    save: Store these settings in ~/.singlestore-mcp/cleanup.json.

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.

Args:
    database: Database (case-sensitive).
    tables: Tables to include (case-sensitive). Omit for every base table in the database.

Refuses unless ``confirm`` is true: call it only after the user saw the plan
(schema_explorer_analyze_plan) and explicitly confirmed. At most 10 tables per call.

Args:
    database: Database (case-sensitive).
    tables: Base tables to analyze (case-sensitive), at most 10.
    confirm: Must be true: the user's explicit confirmation.

Shows every node (aggregators and leaves) with CPU, memory and disk
usage, and the queries running right now, with auto-refresh. Use this
when the user wants to see cluster load, resource usage or what is
running.

The result includes ``browser_url``, which opens this view full-window in
the user's browser: post it as a clickable link right under the app.

Args:
    force: Measure the SingleStore directories again now (otherwise a measurement up to a minute old is reused).

Args:
    warn_days: Flag databases whose last successful backup is older than this many days.

Args:
    range: "1h", "24h" or "7d".
    sample_now: Take one sample now first (otherwise only the local store is read; no cluster query).

Tool results aren't cached by hosts, unlike resources/read, so views pick
up changes right after restart_server.

``head``: the caller's shared-head hash (its ``s2-head`` meta); when it matches,
the page comes without the shared head (``head_omitted``; the caller puts its own
copy in at SHARED_HEAD_MARKER). ``build``: the build the caller already has; when
it matches, only ``unchanged`` comes back.

A slim rail on the left switches between the SQL Editor (schema tree,
editor with autocomplete for keywords, SingleStore functions, databases,
tables and columns, and a results pane), the Schema Explorer, the Pipeline
Monitor and the Cluster Monitor. Use this when the user wants to write,
edit or run SQL themselves, or wants the combined workspace. To run a
query for your own reasoning use run_sql; to show results use query_grid.
The editor has a chat panel: questions from it arrive in the conversation
tagged "[SQL Editor <id>]"; answer those with sql_editor_reply.

The editor has tabs; `sql` goes into the active tab, below the user's
text (or into a new tab with new_tab=true).

The result includes ``browser_url``, which opens this view full-window in
the user's browser: post it as a clickable link right under the app.

Args:
    database: Database to start in (case-sensitive).
    sql: SQL to put in the editor (not run automatically).
    view: View to show first: "sql" (default), "notebook", "schema", "pipelines", "cluster", "history" (Query History), "alerts", "workload" or "connections".
    table: For view="schema": table to pre-select in `database`.
    new_tab: With `sql`: open it in a new editor tab instead of the active one.

Returns as soon as the first ``max_rows`` rows (the first page) are in, or the result is complete; the
rest keeps loading on the server (up to SINGLESTORE_MCP_EDITOR_MAX_ROWS, default 100,000 rows) and the
app pages through it with sql_editor_rows (``done`` / ``loaded`` give the progress and the total).
``stream_id`` is chosen by the app, so its Stop (sql_editor_stop) works before this call returns;
``replaces``: the tab's previous result, dropped. Statements that change data or schema are answered
with ``needs_confirmation`` instead of running; the app then asks the user and uses
sql_editor_execute. Every run lands in the editor's history (when it has finished), with the tab
(``tab_id``, its label ``tab``) and open ``file`` it ran from.

At most ``limit`` rows and about 2 MB per call. ``wait_ms``: wait up to this long for rows past
``offset`` (or the end) while the result is still loading, instead of polling.

Same check as sql_editor_query, without running anything.

``path`` defaults to the SQL folder. Only folders inside the allowed roots
(the user's home folder, the SQL folder, SINGLESTORE_MCP_FILE_ROOTS) can be browsed.

``name``: a local file (relative to the SQL folder, or absolute), or a SAS Viya file ref
(``sas-content://<connection>/<path>`` or ``sas-server://<connection>/<path>``, see viya_files_browse);
a Viya file's result has its ``version`` (ETag), which sql_editor_save_file checks before overwriting.
``remember`` puts it on the Recent list (false when the editor only
re-reads its open file to compare it with the restored draft).

An existing file is only replaced with ``overwrite``; otherwise the result
says ``exists`` so the app can ask first.

SAS Viya files (``name`` a ``sas-content://`` / ``sas-server://`` ref): ``expected_version`` is the version
(ETag) the editor opened; when the file on Viya is newer the result says ``conflict`` (nothing written) and
the app asks before saving with ``overwrite``. A ref of another SAS Viya connection than the active one
answers ``connection_mismatch``; ``use_active`` saves it to the same path on the active connection.

``location``: "content" (SAS Content; starts in My Folder, shortcuts Public and all folders) or "server" (the
SAS Compute server's file system, in the Workspace's SAS session; starts in the first lockdown path, else the
session's home). Each file has ``ref``, the name sql_editor_open_file / _save_file take.

``file_version``: for a file on SAS Viya, the version (ETag) the editor opened or last saved, so Save after
a restart still notices a newer version on the server.

``saved_hash`` is the editor's hash of the open file's last saved text, so a
restored draft knows whether it has unsaved changes; ``dirty`` says so for
the tab bar. ``origin``: the workload statement the tab was opened from
(``{"workload", "statement_id", "statement_name"}``), for "Update in workload".
``language``: what the tab runs as (singlestore, procsql, fedsql, cas); ``sas``: its SAS library / caslib
and PROC SQL options (outobs, noexec, feedback, pushdown).
``closed`` in the result: the tab was closed (elsewhere) and the text wasn't kept.

``profile`` picks speed vs depth: "fast", "balanced" (default) or "thorough".

SQL cell results become pandas DataFrames for the Python cells; Python has
pandas, matplotlib and `conn` (a SingleStore connection). Notebooks are
.ipynb files in the user's SQL folder. It's also the Notebook view of the
SingleStore Workspace (sql_editor with view="notebook").

The result includes ``browser_url``: post it as a clickable link under the app.

Args:
    name: Notebook file to open (e.g. "sales.ipynb"); omit for a new notebook.
    database: Database for SQL cells (case-sensitive).

cell_type "sql": a SingleStore statement whose result becomes a DataFrame
(``df``, and ``name`` if given). Statements that change data or schema
come back with ``needs_confirmation`` unless ``confirmed``.
cell_type "python": Python code, run as-is.
cell_type "sas": SAS code (DATA steps, PROCs) in the SAS Viya session; libref S2 = the notebook database.

It's also the Connections view of the SingleStore Workspace. The result
includes ``browser_url``: post it as a clickable link under the app.

Uses SingleStore's query history (event tracing, information_schema.MV_TRACE_EVENTS). Use this when the
user asks about slow / long-running queries or jobs over time (the Cluster Monitor shows only what's
running now).

Args:
    min_seconds: Only queries that ran at least this long (minimum 1).
    hours: Only the last N hours (default: everything in the history).
    tab: "queries" (default), "trends" (daily / hourly load, failures and p95 from a local copy of the history
        kept across the cluster's ring buffer, plus queries that got slower), "usage" (most used tables and
        most active users) or "advisor" (table-design advice from the whole history).

The result includes ``browser_url``: post it as a clickable link right under the app.

Every distinct query in the history is EXPLAINed (compiled, not run) to see which columns it filters,
joins and groups on, weighted by how long those queries ran. Opens the Query History app on its Advisor tab.

The result includes ``browser_url``: post it as a clickable link right under the app.

The result includes ``browser_url``: post it as a clickable link right under the app.

Args:
    name: Workload to select (optional).

The result includes ``browser_url``: post it as a clickable link right under the app.

Args:
    name: The workload.
    label: A short label for this run.
    duration_s: Override the workload's duration for this run.
    concurrency: Override the number of connections for this run.

Tabs: "users" (every user with type, lock status, password age and expiry, default resource pool, groups,
connections and risk flags such as ALL/SUPER on *.*, host '%', password never expires, locked, unused),
"roles" (user -> group -> role -> privileges, and "who can access" a database or table) and "pools"
(resource pool limits and live status, the workload manager queue with the limit each queued query waits
for, and which users use which pool). Nothing is changed: where a change would help, the view shows SQL
the user can copy.

The result includes ``browser_url``, which opens this view full-window in the user's browser: post it
as a clickable link right under the app.

"How" is "direct" (granted to the user), "via role R ← group G" (user -> group -> role), on the database /
table itself or globally on *.*. Administrative global privileges that don't open data (CREATE USER,
PROCESS, ...) and USAGE are left out. Read-only. Opens the Security view on this lookup.

Args:
    database: Database name (exact).
    table: Optional table in that database.

Args:
    user: User name.
    host: Host part ('%' etc.). Needed only when the name exists for several hosts.

Args:
    action: {"action": one of create_user, drop_user, grant, revoke, revoke_all, create_role, drop_role,
        create_group, drop_group, grant_role, revoke_role, grant_group, revoke_group, create_pool, alter_pool,
        drop_pool, set_default_pool, grant_pool, revoke_pool, plus its fields: user, host, role, group,
        grantee_type ("user"/"role"), privileges, database, table, with_grant_option, grant_option, pool,
        settings, default_pool}. Never a password.
    pending: The changes already in the script basket (same shape), for a change that needs objects they
        create (the plan then says ``needs_script``).

Args:
    actions: The changes, each the same object as for security_change_plan.
    keep_order: Keep the given order instead of the safe order.

Refuses unless ``confirm`` is true: call it only after the user saw the plan (security_change_plan) and
explicitly confirmed. Where the plan asks for it (DROP, revoke all, the connected user or an admin user),
``typed_confirmation`` must be the name the user typed. The plan is rebuilt from fresh cluster state first,
and blockers (lock-out, last admin) refuse the change. ``password`` (create_user only) is sent as a bound
parameter and never returned, logged or stored.

Args:
    action: The same action object as for security_change_plan.
    confirm: Must be true: the user's explicit confirmation.
    typed_confirmation: The object name the user typed, when the plan requires it.
    password: The new user's password (create_user only).

Marks variables whose value differs from the documented default (defaults come from the docs page for the
cluster's version, downloaded once and kept locally) and variables whose value differs between nodes.
Opens the Config view; nothing is changed.

Args:
    search: Only variables whose name, description or category contains this text.
    changed_only: Only variables changed from the default or differing between nodes.

The result includes ``browser_url``, which opens this view full-window in the user's browser: post it
as a clickable link right under the app.

``language``: procsql, fedsql or cas. The SQL is wrapped (proc sql; … quit; etc.); text starting with
proc / data / % runs as plain SAS code. Statements that write anywhere but WORK / CASUSER are answered with
``needs_confirmation`` (the app asks, then calls sas_execute). ``pushdown`` adds sastrace / the FedSQL plan
and returns what was sent to SingleStore with a verdict. ``history`` false: not recorded in the editor's
run history (the Schema Explorer's previews).

Use this for SELECT/DML/DDL that isn't pipeline-specific. For creating,
altering, starting, stopping, dropping or inspecting Pipelines, prefer
the dedicated pipeline tools -- they validate the statement type and are
easier to call correctly.

Args:
    sql: The statement to execute.
    database: Database to run it against (defaults to the connection's
        configured database).
    max_rows: Truncate returned rows to this many (does not affect how
        many rows the statement itself processes).

Args:
    database: Database to list tables from (defaults to the connection's
        configured database).

Args:
    table: Table name.
    database: Database the table lives in (defaults to the connection's
        configured database).

Args:
    database: Database to list pipelines from (defaults to the
        connection's configured database).

Equivalent to SHOW PIPELINES filtered down to a single pipeline. Returns
an empty row list if no pipeline with that name exists.

Args:
    pipeline_name: Name of the pipeline to look up.
    database: Database the pipeline lives in (defaults to the
        connection's configured database).

Args:
    pipeline_name: Name of the pipeline.
    database: Database the pipeline lives in (defaults to the
        connection's configured database).

Pipeline definitions vary a lot by source (S3, Kafka, Azure Blob, GCS,
filesystem, ...), format (CSV/JSON/Avro/Parquet) and optional transforms,
so this tool takes the complete statement text rather than trying to
model every variant as separate parameters. It only checks that the
statement actually starts with CREATE [OR REPLACE] PIPELINE before
running it. Creating a pipeline does not start it -- call start_pipeline
afterwards, or include FOREGROUND handling via start_pipeline.

Example create_pipeline_sql:
    CREATE PIPELINE my_pipeline AS
    LOAD DATA S3 's3://my-bucket/path/'
    CONFIG '{"region": "us-east-1"}'
    CREDENTIALS '{"aws_access_key_id": "...", "aws_secret_access_key": "..."}'
    INTO TABLE my_table
    FIELDS TERMINATED BY ',';

Args:
    create_pipeline_sql: The full CREATE PIPELINE ... statement.
    database: Database to create the pipeline in (defaults to the
        connection's configured database).

Commonly used to change the connection string/credentials or reset
offsets. Takes the full statement for the same reason as create_pipeline:
the set of alterable clauses is source-specific.

Args:
    alter_pipeline_sql: The full ALTER PIPELINE ... statement.
    database: Database the pipeline lives in (defaults to the
        connection's configured database).

Args:
    pipeline_name: Name of the pipeline to start.
    database: Database the pipeline lives in (defaults to the
        connection's configured database).
    foreground: If true, run synchronously and report rows loaded /
        errors in the result instead of returning immediately. Useful
        for a one-off load or for testing a pipeline end to end.
    limit_batches: Only valid with foreground=True: stop after this many
        batches instead of running indefinitely.
    if_not_running: Add IF NOT RUNNING so starting an already-running
        pipeline is a no-op instead of an error.

Args:
    pipeline_name: Name of the pipeline to stop.
    database: Database the pipeline lives in (defaults to the
        connection's configured database).

Args:
    pipeline_name: Name of the pipeline to drop.
    database: Database the pipeline lives in (defaults to the
        connection's configured database).
    if_exists: Add IF EXISTS so dropping a nonexistent pipeline is a
        no-op instead of an error.

The pipeline must already exist and must be stopped first (SingleStore
errors if you test a running pipeline) -- call stop_pipeline before this
if needed. Nothing is written to the destination table; this is purely
for validating that the source/format/transform config works.

Args:
    pipeline_name: Name of the pipeline to test.
    database: Database the pipeline lives in (defaults to the
        connection's configured database).
    limit: Only pull this many rows/messages instead of testing the
        whole batch.

Use this when the user wants an app bigger than the chat allows or in
their browser. Give the user the returned URL as a clickable link. It
works on this machine only, until the MCP server restarts.

Args:
    tool: The app tool: pipeline_monitor, query_grid, schema_explorer, cluster_monitor or sql_editor.
    arguments: That tool's arguments, e.g. {"sql": "...", "database": "SASDP"}
        for query_grid or {"database": "SASDP", "table": "CARS"} for
        schema_explorer.

Use this to answer a message that arrived from the SQL Editor (it starts
with "[SQL Editor <editor_id>]") or the Workload view's chat ("[Workload
<id>]": each ```sql block gets Add to workload / Replace / Test buttons there,
optionally preceded by "-- name: …" and "-- per_minute: N" lines), or when the user asks you to put SQL into
their open editor (the editor reports its id in the model context). The
message is plain text; put SQL in ```sql fenced blocks - each block gets
Replace / Insert / Copy buttons in the editor. Keep explanations short.
After calling this, reply briefly in the chat as well.

Args:
    editor_id: The editor's id, e.g. "e-4f9a2c".
    message: The answer, with SQL in ```sql fenced blocks.

All tools and apps use the active connection. The user manages them in the
Connections window (connections_window tool, or the workspace's Connect view).

Args:
    name: Name of a saved connection (see list_connections).

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.