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`.

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.

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.

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

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 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" or "connections".
    table: For view="schema": table to pre-select in `database`.

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.

``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.

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

``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) 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.

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 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).