Diogenes Database Intelligence, SQL Engine & Schema Guard MCP

Deterministic NL-to-SQL Synthesizer & Dialect Query Generator

synthesize_sql_query

Read-onlyIdempotent

Translates natural language questions into dialect-accurate, optimized SQL SELECT queries using schema awareness and safety checks for reporting and automated data analytics pipelines.

Instructions

Translates natural language questions into dialect-accurate, optimized SQL SELECT queries with schema awareness and safety checks. Use when generating reporting queries or automated data analytics pipelines; for analyzing SQL execution performance and EXPLAIN plans, use analyze_query_plan instead. Stateless read-only edge call (max 32 KB, 60 RPM): accepts 'natural_language_request' and 'schema_ddl' ('sql_dialect' defaults to 'postgresql_dialect'), supports '?demo=true' or L402 (15 sats), and returns HTTP 400 if invalid.

Input Schema

Name	Required	Description
`schema_ddl`	Yes	Database schema DDL statements defining available tables, columns, and relations.
`sql_dialect`	No	Target SQL dialect specification: PostgreSQL dialect, MySQL dialect, or SQLite dialect.
`read_only_mode`	No	Whether to enforce strict read-only SELECT query constraints.
`natural_language_request`	Yes	Natural language question or reporting requirement to transform into SQL.

Output Schema

Name	Required	Description
`dialect`	Yes	Database engine dialect target the query was generated for.
`sql_query`	Yes	Synthesized, formatted SQL query tailored to the provided schema and dialect.
`query_type`	Yes	Operation classification (e.g., SELECT_AGGREGATE, SELECT_JOIN, FILTERED_SCAN).
`explanation`	Yes	Step-by-step rationale explaining table joins, filtering predicates, and grouping logic.
`safety_checked`	Yes	True if AST static analysis verified the query has zero mutation side-effects.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 26, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description adds substantial behavior beyond the annotations: it is stateless and read-only, capped at 32 KB and 60 RPM, defaults sql_dialect to postgresql_dialect, supports demo mode or L402 payment, and returns HTTP 400 for invalid input. These operational constraints and failure modes are exactly the kind of context annotations alone do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded: purpose first, usage and alternative second, operational constraints third. Every sentence contributes distinct information, and the parenthetical details are dense but purposeful rather than ornamental.

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?

With full schema coverage, annotations, and an output schema present, the description supplies the remaining operational context an agent needs: statelessness, size and rate limits, dialect default, payment/demo behavior, and error behavior. Nothing important for correct invocation appears to be 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 already 100%, so the schema carries most parameter meaning. The description adds useful semantics by noting that sql_dialect defaults to 'postgresql_dialect', but it does not add much about read_only_mode or the required inputs beyond naming them.

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?

The description gives a specific verb and resource: translating natural language questions into dialect-accurate, optimized SQL SELECT queries with schema awareness and safety checks. It also explicitly distinguishes the tool from the sibling analyze_query_plan, so an agent can tell when this is the right NL-to-SQL generator rather than a query-plan analyzer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the intended use cases directly: generating reporting queries or automated data analytics pipelines. It also names a concrete alternative, analyze_query_plan, for SQL execution performance and EXPLAIN plans, which gives the agent a clear routing rule.

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

Deploy Server