Skip to main content
Glama
singlestore-mcp-server

singlestore-mcp-server

by jonasliesas

sas_query

Read-only

Run one SQL statement as PROC SQL, FedSQL, or CAS SQL against SAS libraries or caslibs, with pushdown tracing and background status handling for long-running queries.

Instructions

Run one statement from the SQL Editor as PROC SQL / FedSQL (SAS libraries) or FedSQL in CAS (caslibs).

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

The run goes to the background: ``run_id`` (chosen by the app, so Stop works at once) names it,
``wait_ms`` is how long to wait for the result (default: until it's done); a run still going is answered
with ``running`` and its status (``waiting_for``: the run in another tab it waits for), and the app asks
again with sas_run_status. ``connection``: the SAS Viya connection (default: the active one).
``max_rows``: rows in the answer; ``table_rows``: rows PROC SQL keeps in the result table for paging
(sas_rows; default ``max_rows``).

Input Schema

NameRequiredDescriptionDefault
sqlYes
tabNo
fileNo
run_idNo
tab_idNo
historyNo
libraryNo
optionsNo
wait_msNo
languageYes
max_rowsNo
pushdownNo
connectionNo
table_rowsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.11.0
    • addedInput schema / properties / connection
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Connection"
      +}
    • addedInput schema / properties / run_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Run Id"
      +}
    • addedInput schema / properties / table_rows
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Table Rows"
      +}
    • addedInput schema / properties / wait_ms
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Wait Ms"
      +}
  2. Addedv0.10.1

TDQS

A3.9/5.0
Behavior4/5

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

Beyond readOnlyHint=true, the description discloses a lot: SQL is auto-wrapped (proc sql; … quit;), text beginning with proc / data / % is treated as plain SAS code, dangerous writes are gated behind needs_confirmation, pushdown changes the returned tracing/plan output, and execution is asynchronous with run_id, wait_ms, and a 'running' status. The only residual tension is that readOnlyHint=true sits alongside a description of statements writing to WORK/CASUSER, though the gated-write language largely explains that away. Return-shape details that would fully close the loop (e.g. row/verdict structure) are implied rather than stated.

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 purpose sentence is front-loaded and the remaining paragraphs are grouped by concern (language/wrapping, confirmation/verification, background execution, sizing), with backticked parameter names making scanning easy. Some sentences are overly compressed to the point of ambiguity — 'pushdown adds sastrace / the FedSQL plan and returns what was sent to SingleStore with a verdict' and the run_id parenthetical are hard to parse on one read.

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 14-parameter, no-output-schema, asynchronous execution tool, the description covers the states an agent must handle (completed result, 'running' + waiting_for, needs_confirmation) which effectively substitutes for a missing output schema. What remains unaddressed is the meaning of the editor-context parameters (tab, file, tab_id, library, options) that a caller may need to supply correctly.

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

Parameters3/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 load, and it does explain language, pushdown, history, run_id, wait_ms, connection, max_rows, and the subtle max_rows-vs-table_rows split (result rows vs paging rows in the sas_rows table). However, five parameters — tab, tab_id, file, library, options — receive no explanation at all, leaving nearly a third of the surface opaque. That gap keeps it at minimum-viable-plus rather than strong.

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 first sentence names a specific verb and resource ('Run one statement from the SQL Editor') and immediately scopes the three language modes (procsql / fedsql / cas) and the library-vs-caslib distinction. It also links forward to sas_execute (for confirmed writes) and sas_run_status (for polling), so the agent can see where this tool sits in the family. It does not explicitly disambiguate against near-siblings such as sql_editor_execute, run_sql, or sas_fedsql_check, which keeps it from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear conditions are stated: writes outside WORK/CASUSER trigger needs_confirmation and route to sas_execute; history=false is for Schema Explorer previews; a still-running job should be re-polled with sas_run_status. What is missing is an explicit statement of when an agent should pick this tool over sql_editor_execute / run_sql, and no exclusions are given.

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