Skip to main content
Glama
s3eidat

S3eidat Tools MCP

by s3eidat
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

SQL query over tables

ai_sql_query
Read-onlyIdempotent

Run read-only SELECT queries across local CSV, JSON, and Excel tables to join, filter, group, and summarize data without uploading files.

Instructions

Run one read-only SQL SELECT (alasql dialect: JOIN, GROUP BY, HAVING, ORDER BY, LIMIT, UNION, WITH, subqueries, CASE, SUM/COUNT/AVG/MIN/MAX/MEDIAN/STDEV, string and date functions) over one or more tables. Each table is { name, file | csv | json }: a local path or base64 of a CSV, TSV, JSON array, JSONL or .xlsx (first sheet, or "sheet"), or inline CSV text / JSON rows. CSV cells are typed (numbers, true/false, empty → null; ISO dates stay ISO text, so they sort and compare correctly; YEAR()/MONTH() work on them). Only SELECT is allowed: INSERT/UPDATE/DELETE/DROP/CREATE/ALTER/ATTACH, SELECT INTO, file readers like FROM CSV(...), inline JavaScript and the -> operator are refused. Table names are case-sensitive; quote odd column names and reserved words (total, value, count, date…) as [My Column]. Returns columns and up to maxRows rows (default 500) with the total count; set "output" (.csv, .tsv, .json, .jsonl or .xlsx) to save every row to a file. Runs locally; nothing is uploaded.

Input Schema

NameRequiredDescriptionDefault
queryYesOne SELECT statement, e.g. SELECT region, SUM(amount) AS revenue FROM sales GROUP BY region ORDER BY revenue DESC
typesNoType CSV cells (numbers, booleans, null). Default true; false keeps every CSV cell as text.
outputNoOptional: save ALL result rows to this file; the type comes from the extension (.csv, .tsv, .json, .jsonl, .xlsx; default .csv).
tablesYesThe tables the query can read (1-20).
maxRowsNoRows to return inline (default 500). "total" always counts all rows.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, it discloses allowed SQL features, refused SQL operations, CSV typing behavior, case sensitivity, quoting rules, inline result limits, output-file behavior, and that processing is local. This gives the agent substantial behavioral context for safe invocation.

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 description is dense but front-loaded with the core operation and then organized into dialect, table formats, restrictions, naming, and return behavior. It is appropriately sized for a complex tool, though the long parenthetical style is packed.

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?

Given the complex querying behavior, no output schema, and many input formats, the description is complete enough: it explains return values, row limits, output options, table input forms, and key restrictions. An agent can call it correctly without further documentation.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds useful semantics: table names are case-sensitive, odd column names should be bracketed, CSV cells are typed, ISO dates remain sortable/comparable, and output saves every row. These details supplement the schema descriptions.

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 description opens with a specific verb and resource: 'Run one read-only SQL SELECT ... over one or more tables.' It clearly defines scope and dialect, though it does not explicitly name sibling alternatives such as json_query or csv_to_json.

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?

It gives clear usage context, including the read-only SELECT restriction and a detailed list of refused statements and operators. It does not explicitly compare against alternative tools, so it stops short of full when-to-use/when-not guidance.

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