Diogenes Microservice Gateway

AST-Level Read-Only SQL Query & Injection Safety Validator

validate_sql_query_ast

Read-onlyIdempotent

Statically parses SQL statements via AST to verify strictly read-only SELECT clauses and reject mutations, stacked queries, or comment bypasses before execution.

Instructions

Performs static AST syntax tree parsing on SQL statements to verify strictly read-only SELECT clauses and reject mutations, stacked queries, or comment bypasses. Use when verifying that an agent-authored SQL statement is strictly read-only before running it on a database; for screening non-SQL bash commands or general agent prompts, use verify_agent_command_safety instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'sql_statement' ('dialect' defaults to 'postgres'), supports '?demo=true' or L402 (15 sats), and returns HTTP 400 if invalid.

Input Schema

Name	Required	Description	Default
`dialect`	No	SQL dialect ruleset used for AST token inspection; defaults to 'postgres' when omitted.
`sql_statement`	Yes	SQL statement string to statically parse and audit for read-only SELECT compliance (e.g. 'SELECT id, email FROM users WHERE active = 1').

Output Schema

Name	Required	Description
`verdict`	Yes	Execution decision ('ALLOW_EXECUTION' or 'BLOCK_EXECUTION').
`safe_read_only`	Yes	True when the query is a pure SELECT statement with zero injection clauses.
`blocked_clauses`	Yes	List of destructive or injection SQL tokens detected.
`tables_accessed`	Yes	Table identifiers referenced in FROM and JOIN clauses.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.3.3Oct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds genuinely new operational context: statelessness, a 32 KB input cap, 60 RPM rate limit, an L402 payment path (15 sats), a '?demo=true' mode, and HTTP 400 on invalid input. These are exactly the constraints an agent needs and are not derivable from annotations or schema.

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?

Two dense sentences, front-loaded with the verb and compliance guarantee, followed by routing and operational limits — no wasted framing. The payment/rate-limit clause is packed tightly mid-sentence, which slightly hurts scannability but every element carries information.

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?

An output schema exists, so return values need no explanation, and the description still covers the remaining gaps an agent would hit: input size ceiling, throughput limit, payment mechanics, and error signaling (HTTP 400). Nothing needed to invoke it correctly is missing.

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 description coverage is 100%, so the baseline is 3; the description modestly exceeds it by restating the 'sql_statement' and default-'postgres' dialect behavior and by surfacing the '?demo=true' selector, which is not represented in the input schema at all. No syntax or size-per-dialect guidance beyond the 32 KB cap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('static AST syntax tree parsing on SQL statements') plus the exact success condition ('verify strictly read-only SELECT clauses') and failure modes rejected (mutations, stacked queries, comment bypasses). An agent can immediately tell this apart from synthesize_sql_query or transpile_sql_dialect.

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?

Explicitly says when to use it ('verifying that an agent-authored SQL statement is strictly read-only before running it on a database') and names an alternative for out-of-scope input ('use verify_agent_command_safety instead'). It does not address the closely overlapping sibling audit_sql_injection_ast, whose injection-rejection remit overlaps the 'stacked queries or comment bypasses' language, leaving one ambiguity unresolved.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server