Skip to main content
Glama
devopam

MCPg - Production-grade PostgreSQL MCP Server

Translate NL to SQL

translate_nl_to_sql
Read-only

Convert a natural-language question into a read-only SQL query, with optional safe execution against your PostgreSQL schema.

Instructions

Translate a natural-language question into a read-only PostgreSQL query against schema. The LLM provider (anthropic / openai / gemini / deepseek / qwen / openrouter / perplexity, plus any operator-declared custom OpenAI-compatible provider) sees a compact brief of the schema (tables, columns, foreign keys) and is instructed to return JSON with sql and explanation. When execute=true, the generated SQL goes through the SAME safety allowlist as run_select before running — writes / DDL / multi-statement input are rejected even if the model produced them. Returns the SQL, model rationale, and (when executed) rows / columns / row_count. table_filter narrows the brief to a known subset when the question is clearly scoped. provider, when supplied, selects which configured LLM provider to call (use this to route between the configured vendors per-call when multiple are configured); when omitted, MCPg uses the default (MCPG_NL2SQL_PROVIDER, otherwise the first available in preference order anthropic → openai → gemini → deepseek → qwen → openrouter → perplexity). Call get_server_info to see which providers are configured.

Example: translate_nl_to_sql(question='top 10 customers by revenue last month', schema='public', execute=true)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
schemaYes
executeNo
databaseNoOptional: target a configured secondary (read-only) database by name; omit for the primary. Call list_databases to see the configured ids.
max_rowsNo
providerNo
questionYes
table_filterNo
explain_preflightNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYes
rowsYes
errorYes
modelYes
columnsYes
refusedNo
executedYes
providerYes
row_countYes
explanationYes
refusal_reasonNo
Behavior5/5

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

Discloses that generated SQL is routed through the same safety allowlist as run_select, rejecting writes/DDL/multi-statement input. Aligns with readOnlyHint annotation. Also explains that the LLM sees a compact schema brief and returns JSON with sql and explanation.

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?

Front-loaded core purpose, each sentence adds value. Includes a clear example. No fluff or repetition. Well-structured explanation of parameters and behavior.

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?

Covers all important aspects: purpose, parameters, safety, output format, provider options, and fallback behavior. Given the complexity (8 params, LLM integration, safety allowlist), the description is thorough and self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds significant meaning beyond the input schema (which has only 13% description coverage). Explains the purpose and behavior of provider, table_filter, execute, and database, including fallback logic and safety implications.

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 explicitly states 'Translate a natural-language question into a read-only PostgreSQL query against schema' and includes a concrete example. It uniquely distinguishes from siblings by specifying LLM-based SQL generation and read-only safety checks.

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?

Provides clear guidance on when to use execute=true, how table_filter narrows the schema brief, and how provider routing works with fallback order. Suggests calling get_server_info to see available providers, but doesn't explicitly state when NOT to use this tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/devopam/MCPg'

If you have feedback or need assistance with the MCP directory API, please join our Discord server