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.4/5 across 5 of 5 tools scored. Lowest: 3.9/5.
Each tool has a clearly distinct purpose: run_sql executes a query, run_sql_batch runs multiple separate queries, validate_sql validates without executing, explain_plan returns query plans, and diff_results compares result sets. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case: diff_results, explain_plan, run_sql, run_sql_batch, validate_sql. The naming is predictable and uniform.
With 5 tools, the server is well-scoped for SQL verification tasks. It provides essential functionality without unnecessary bloat, covering execution, validation, planning, and result comparison.
The tool surface covers the full lifecycle of SQL verification: validation (validate_sql), execution (run_sql, run_sql_batch), plan analysis (explain_plan), and result comparison (diff_results). No obvious gaps for the stated purpose.
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 that identical fresh databases are used, comparison is order-insensitive, order divergence is reported separately, and diffs are capped. This provides comprehensive 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?
The description is three sentences long, front-loaded with the key question, and each sentence adds essential information without redundancy. It is efficient and well-structured.
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 5 parameters (3 required), no output schema, and nested objects, the description covers return structure (equal, row counts, diffs) and execution model (fresh databases). It is sufficiently complete for an agent to understand usage and output.
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 beyond the schema by clarifying engine limitations (duckdb only in browser demo) and seed size limit (10MB). This extra context justifies a score of 4.
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 'Answer "do these two queries return the same thing?" — the self-check for query refactors.', specifying the primary use case. It distinguishes from sibling tools like run_sql and explain_plan by focusing on diffing 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 labels the tool as a self-check for query refactors, giving clear usage context. It does not explicitly list when not to use or name alternatives, but the context is sufficient for most agents.
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?
No annotations provided, so description carries full burden. It discloses engine-specific behavior (SQLite EXPLAIN, DuckDB demo only) and full-table-scan warnings. However, it does not explicitly state that the operation is read-only or describe output format beyond the example.
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 well-structured sentences plus a clarifying example. Every sentence adds value: purpose, usage, example. No unnecessary 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 3 parameters, no output schema, and no annotations, the description covers purpose, usage scenario, example, and engine constraint. It could be improved by detailing the output format, but the example provides sufficient clarity for an AI agent.
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 emphasizing the importance of including indexes in the schema DDL and clarifying engine limitations. The query parameter is straightforward, but the overall context aids correct 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 engine-native query plans and full-table-scan warnings, using a specific verb ('Return') and resource ('query plan'). It distinguishes itself from sibling tools by focusing on 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 when to use ('check whether an index would be used before recommending one') and provides a concrete example. Does not explicitly mention when not to use, but context of sibling tools implies alternatives.
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 provided, the description carries the full burden. It discloses key behaviors: ephemeral in-memory database, max 500 rows with truncation flag, structured error responses with type/position/suggestion, engine limitations (duckdb only in browser), and seed size limit (10MB). It does not contradict any annotations.
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, front-loading the core purpose and then detailing return values, error handling, and examples. It is concise enough while covering all essential aspects. Minor improvements could be made by using bullet points for clarity.
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 tool's complexity (4 params, nested objects, no output schema), the description is reasonably complete. It explains the return format (rows, columns, row_count), error handling, engine options, and maximum limits. It meets the needs for an AI agent to understand invocation and outcomes.
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 description coverage is 100%, so the baseline is 3. The description adds context (e.g., engine notes, seed limit, query restriction to one statement) but does not significantly extend the schema's descriptions. The example clarifies parameter use but adds no new semantic details.
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 a fresh ephemeral database built from schema and optional seeds. It specifies return values (max 500 rows, truncation flag, column info, row count, dialect notes), error format, and provides an example. It implicitly distinguishes from siblings like run_sql_batch by noting only one SQL statement is accepted.
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 does not explicitly state when to use this tool versus alternatives like validate_sql or run_sql_batch. While it implies use for single ad-hoc queries by noting stacked statements are rejected, there is no direct guidance on when not to use it or what prerequisites exist.
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?
No annotations are provided, so the description must fully disclose behavior. It mentions isolation, query limit (10), and return format (array of run_sql results in order). However, it does not cover error handling or partial failure behavior, which is a minor gap.
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 with no wasted words. The first sentence states the core function and limits, the second adds critical behavioral context. Highly 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?
Given the tool's complexity (4 params, nested objects, optional seed, enum engine) and no output schema, the description provides essential information: purpose, usage guidance, key behavioral traits, and return format. Minor gaps like error handling keep it from a 5.
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 does not add additional parameter-level meaning beyond what the schema provides (e.g., it does not repeat seed size or engine constraints). The isolation and batch aspects are behavioral, not parameter-specific.
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 runs up to 10 queries against the same schema+seed, emphasizes isolation (each query in its own fresh database), and distinguishes from multi-statement transactions, indicating usage for testing variants. This contrasts effectively with sibling tools like run_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 explicitly states when to use (testing variants) and when not to (not for multi-statement transactions). It implies using run_sql for single queries but does not name the alternative directly. Overall, the context 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, but description fully discloses behavior: uses EXPLAIN, does not execute, returns structured errors with type, message, position, and suggestion (rule-based edit distance). No contradictions.
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: purpose, return format, example. No extraneous words. Well-structured 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?
Fully describes behavior, return values for success and error, and parameter specifics. No output schema needed.
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 descriptions cover all parameters (100% coverage). Description adds value by explaining engine limitations (duckdb only in browser demo), error format, and provides an example, going beyond the schema.
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?
Clearly states 'Validate a SQL query against a schema WITHOUT executing it' and explains return values (ok with tables or structured errors). Distinguished from siblings like run_sql and explain_plan by emphasizing no execution.
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 notes the tool does not execute, implying use for validation only. Does not provide explicit when-not or compare to explain_plan, but the sibling names and description make usage clear.
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!