PreSQL
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SQL_GUARD_DDL | No | Inline DDL, e.g. CREATE TABLE users (id INT, email VARCHAR(255)); Alternative to the --schema CLI flag and the SQL_GUARD_SCHEMA env var. | |
| SQL_GUARD_SCHEMA | No | Path to a schema file (e.g. ./schema.sql). Alternative to the --schema CLI flag and the SQL_GUARD_DDL env var. |
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 |
|---|---|
| validate_sqlA | Validate a SQL statement against the configured schema. Returns a verdict (safe/review/blocked), a list of issues with codes, severities, messages and fix suggestions, plus a plain-English explanation. Call this before executing AI-generated SQL. |
| explain_sqlA | Explain a SQL statement in plain English. No verdict, no judgment — for understanding what a query does before deciding whether to run it. |
| guard_queryA | Pre-execution safety hook for AI-generated SQL. Returns a go/no-go decision (allow/review/block) with a human-readable reason and the underlying verdict. Designed to be called before handing SQL to a database MCP server or executing it. |
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 3 tools
validate_sql and guard_query overlap heavily: both return a safety verdict (safe/review/blocked vs allow/review/block) with reasons, differing mainly in framing. explain_sql is clearly distinct (no judgment), but an agent could easily struggle to choose between validate and guard.
All three tools follow a clean verb_noun snake_case pattern (validate_sql, explain_sql, guard_query) with no mixing of conventions.
Three tools is well-scoped for a focused SQL safety server, though the overlap between validate_sql and guard_query makes one of them feel somewhat redundant rather than each earning a distinct place.
The domain (pre-execution SQL validation and understanding) is largely covered: validate, explain, and guard. Coverage is adequate, though the surface is thin and could benefit from e.g. schema-aware fix application or batch validation.