sqlai.dev SQL Verifier
Server Details
Executes SQL in a real ephemeral database: rows, typed errors with suggestions, plans, diffs.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 5 of 5 tools scored.
Each tool has a distinct, non-overlapping purpose: comparing query results, explaining query plans, executing queries singly or in batch, and validating queries without execution. No ambiguity.
All tools follow a consistent verb_noun pattern (e.g., diff_results, run_sql, validate_sql). Even run_sql_batch extends the pattern with a clear suffix. No mixed conventions.
With 5 tools, the server is well-scoped for SQL verification without unnecessary bloat. Each tool addresses a core need: execution, comparison, planning, validation, and batch execution.
The tool set covers all essential operations for SQL verification: execute, validate, compare, and plan. No obvious missing operations for the stated purpose of verifying and analyzing SQL queries.
Available Tools
5 toolsdiff_resultsAInspect
Answer "do these two queries return the same thing?" — the self-check for query refactors. Executes query_a and query_b against identical fresh databases and compares result multisets (order-insensitive; order divergence reported separately when ORDER BY is present). Returns equal:boolean, row counts, and capped row-level diffs (only_in_a / only_in_b).
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Optional seed rows: {"table_name": [{"col": value, ...}, ...]}. Max 10MB total. | |
| engine | No | Engine. Server-side supports 'sqlite' (default). 'duckdb' runs in the browser demo at sqlai.dev only. | |
| schema | Yes | DDL statements. | |
| query_a | Yes | Original query. | |
| query_b | Yes | Refactored/alternative query. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: executes against fresh databases, compares multisets with order-insensitivity, reports order divergence when ORDER BY is present, and returns specific output fields (equal, row counts, diffs). It does not explicitly state read-only nature, but this is implied by the comparison semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences and a brief list of return fields. It starts with the core purpose, then covers behavior and output. Every sentence adds unique information without redundancy. Excellent front-loading and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the return values (equal, row counts, row-level diffs) and edge-case handling (order divergence). The 5 parameters are explained in the schema and supplemented by description notes. For a comparison tool with moderate complexity, the description is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by providing constraints on seed (max 10MB total), clarifying the engine's server/demo scoping, and explaining the purpose of query_a and query_b as 'original' and 'refactored/alternative.' This extra context helps the agent understand parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb phrase ('Answer do these two queries return the same thing?') and names the specific resource (query comparison). It explicitly frames the tool as a 'self-check for query refactors,' which distinguishes it from siblings like run_sql or validate_sql.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states this is for query refactors and explains the execution context (fresh databases, order-insensitive comparison). However, it does not explicitly say when not to use the tool or mention alternatives like manually running both queries via run_sql. The guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_planAInspect
Return the engine-native query plan for a query (SQLite: EXPLAIN QUERY PLAN) plus full-table-scan warnings. Use it to check whether an index would be used before recommending one. Example: "SELECT * FROM orders WHERE status=?" on an unindexed column → plan ["SCAN orders"], warning about the full scan.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ONE SQL statement to explain. | |
| engine | No | Engine. Server-side supports 'sqlite' (default). 'duckdb' runs in the browser demo at sqlai.dev only. | |
| schema | Yes | DDL statements (include your indexes!). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns a plan and warnings, and notes the limitation that 'duckdb' only works in browser demo. However, it does not explicitly state that the tool is read-only or idempotent, which is implied but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and an example, all front-loaded with the main purpose. Every sentence adds necessary information without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (3 params, no output schema, no annotations), the description fully covers how to use the tool, what it returns (with example output), parameter details, and a notable limitation (duckdb scope). It is complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying 'query' is a single SQL statement, explaining 'engine' default and limitation, and emphasizing 'schema' must include indexes. The example further illustrates parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the engine-native query plan and full-table-scan warnings, specifying the verb 'return' and resource 'engine-native query plan'. It distinguishes itself from siblings like 'run_sql' and 'validate_sql' by focusing on plan analysis rather than execution or validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use it to check whether an index would be used before recommending one.' and provides a concrete example illustrating when to use. This gives clear guidance on the tool's intended use case, effectively differentiating it from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_sqlAInspect
Execute a SQL query against a fresh ephemeral in-memory database built from your schema (and optional seed rows). Returns real rows (max 500, truncation flagged), column names+types, row_count, and dialect notes. Errors come back as structured JSON with type/position/suggestion — a failed query is a useful answer, not a failure of this tool. Example: schema "CREATE TABLE t(id INTEGER, name TEXT);", query "SELECT name FROM t WHERE id=1", seed {"t":[{"id":1,"name":"ada"}]} → rows [["ada"]].
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Optional seed rows: {"table_name": [{"col": value, ...}, ...]}. Max 10MB total. | |
| query | Yes | ONE SQL statement to execute. Stacked statements are rejected. | |
| engine | No | Engine. Server-side supports 'sqlite' (default). 'duckdb' runs in the browser demo at sqlai.dev only. | |
| schema | Yes | DDL statements (CREATE TABLE ...; multiple statements allowed). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it discloses ephemeral nature, row limit (500 with truncation flag), return structure (columns, types, count, dialect notes), error format (structured JSON with type/position/suggestion), and provides an example. No behavioral gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then return details, error handling, and a concrete example. Every sentence adds value, no fluff. It is appropriately sized for a tool with 4 parameters and moderate complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains return values (rows, columns, types, row_count, truncation flag, dialect notes) and error behavior. It covers all critical aspects for proper invocation and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying constraints: seed max 10MB, query must be a single statement, engine defaults to 'sqlite' and 'duckdb' is browser-only. This goes beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a SQL query against an ephemeral in-memory database, specifies the verb ('Execute'), resource ('SQL query'), and environment ('fresh ephemeral in-memory database'). It differentiates from siblings like validate_sql and explain_plan by focusing on execution and result retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description describes what the tool does but lacks explicit guidance on when to use it vs alternatives like run_sql_batch or validate_sql. The usage is implied from context, but no exclusionary or comparative language is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_sql_batchAInspect
Run up to 10 queries against the same schema+seed. Each query executes in its OWN fresh database — writes in one query are NOT visible to the next (use this for testing variants, not for multi-statement transactions). Returns an array of run_sql results in order.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Optional seed rows: {"table_name": [{"col": value, ...}, ...]}. Max 10MB total. | |
| engine | No | Engine. Server-side supports 'sqlite' (default). 'duckdb' runs in the browser demo at sqlai.dev only. | |
| schema | Yes | DDL statements. | |
| queries | Yes | Up to 10 statements, one per entry. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses key behaviors: each query runs in its own fresh database, writes are not visible across queries, and results are returned in order. This is sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. The first sentence states the core purpose, the second clarifies a critical behavioral nuance, and the third specifies the return format. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, isolation, return format, and parameter hints. It lacks explicit return schema details, but references 'run_sql results' which implies a known structure. Adequate for the tool's moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond the schema by explaining isolation semantics and the batch limit. The description compensates for the lack of detailed parameter info with behavioral context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run up to 10 queries'), the resource ('same schema+seed'), and distinguishes it from siblings like run_sql by emphasizing batch execution and isolation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells when to use ('for testing variants') and when not ('not for multi-statement transactions'). It does not name a specific sibling alternative for transactions, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_sqlAInspect
Validate a SQL query against a schema WITHOUT executing it (parse + name/type binding via EXPLAIN). Returns ok with referenced tables, or a structured error: {type: unknown_column|unknown_table|syntax|..., message, position, suggestion}. The suggestion is rule-based (edit distance against your schema). Example: query "SELECT nmae FROM users" → error type unknown_column, suggestion 'did you mean "name"?'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ONE SQL statement to validate. | |
| engine | No | Engine. Server-side supports 'sqlite' (default). 'duckdb' runs in the browser demo at sqlai.dev only. | |
| schema | Yes | DDL statements. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: parsing via EXPLAIN, returning structured errors with type, message, position, suggestion. It explains the suggestion is rule-based (edit distance) and gives an example, leaving no ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single efficient paragraph with clear structure, includes an illustrative example, and no wasted text. Could be slightly more structured but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description thoroughly explains the return format, including error types and suggestion logic. It covers all essential aspects for a validation tool, providing complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100%), so baseline 3. Description adds value by specifying query is 'ONE SQL statement', detailing engine defaults and limitations, and clarifying schema is DDL statements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates SQL without executing it, using a specific verb 'validate'. It distinguishes from siblings like run_sql and run_sql_batch which execute queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes it does not execute, implying use for validation only. It mentions engine constraints (duckdb only in browser demo), providing clear context. Could be more explicit about when not to use, but the sibling names help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!