SQAI
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SQAI_API_KEY | No | API key for authentication with SQAI (optional) | |
| SQAI_SOURCES | No | JSON string representing an array of source definitions, e.g. [{"data": "./data/sales.csv", "name": "sales"}] | |
| SQAI_DEPLOYMENT_URL | No | Deployment URL for the SQAI service (optional) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| listSourcesA | Discover what SQAI can touch. No arguments: list connected data sources with exact field names, types, and allowed operations — call this before queryData so specs use exact names. With capabilitySearch: search the deterministic computation catalog and get matching modules. With module: list that module's functions with exact signatures. Execution requires a free community login ( |
| queryDataA | Execute one deterministic, read-only SQAI request. Use kind 'query' for tabular questions (aggregations, grouping, filtering) over connected sources — call listSources first for exact field names. Use kind 'computation' for math (statistics, financial, vector/matrix, simulation) over arrays: never paste large data into args — use bindings to pull columns from connected sources. Simulation modules require a seed. Large results are truncated for context; the full result stays retrievable — pass the returned result_id to the getResult tool. Execution requires a free community login ( |
| explainQueryA | Dry-run a queryData request without executing it. kind 'query': resolve and verify the plan (resolved_plan, plan steps, plan_hash, confidence, validated). kind 'computation': check the capability exists and get its exact signature, a preview invocation_hash, and whether a seed is required. Use this to debug clarifications and rejections before running queryData. Execution requires a free community login ( |
| getResultA | Fetch the full stored result of an earlier queryData call by its result_id. Use it when queryData returned truncated: true — the preview is capped for context, this returns every stored row/element (only results within the output-size cap, 10 MB by default, get a result_id at all). The store is in-memory and short-lived: default 15-minute TTL, evicted oldest-first under memory pressure. An unknown, expired, or evicted result_id returns a structured result_not_found error — re-run the original queryData request to regenerate. Read-only and idempotent; takes no other parameters. Execution requires a free community login ( |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct role: queryData executes, explainQuery dry-runs, getResult retrieves stored results, and listSources discovers sources/capabilities. Even the closely related queryData and explainQuery are unambiguously separated by execution versus planning. No two tools appear to do the same thing.
All four tool names follow the same camelCase verb_noun pattern: queryData, getResult, explainQuery, listSources. The naming is uniform and predictable, making the API easy to navigate. There are no mixed conventions or vague verbs.
Four tools is a well-scoped count for a read-only query and computation server. Each tool covers an essential stage of the workflow: discover, explain, execute, and retrieve. No tool feels redundant or missing from the core flow.
The tool surface fully covers the stated purpose: discovering data sources and computation modules, validating queries before execution, executing queries, and retrieving truncated results. The read-only nature means CRUD operations are not expected, so there are no obvious dead ends. The workflow is cohesive and self-contained.