Skip to main content
Glama

Raw SQL Query

db_raw_query
Read-onlyIdempotent

Execute raw SQL SELECT queries with mandatory LIMIT for complex joins, CTEs, and window functions that structured tools cannot express. Runs in a read-only transaction with row caps and blocked dangerous functions.

Instructions

Executes a raw SQL SELECT statement with a mandatory LIMIT clause. This is the escape hatch for queries that cannot be expressed with the structured tools (complex JOINs, CTEs, window functions, subqueries, etc.). All queries run inside a read-only, single-statement transaction with a configurable timeout (default 10 seconds).

When to use:

  • Complex JOINs across multiple tables

  • CTEs, window functions, or subqueries

  • Custom aggregations not supported by db_aggregate

  • Exploratory queries during development

Parameter guidance:

  • sql: the raw SQL statement (required). Must be a SELECT and MUST include a LIMIT clause. Example: "SELECT u.name, COUNT(o.id) FROM users u JOIN orders o ON o.user_id = u.id GROUP BY u.name ORDER BY COUNT(o.id) DESC LIMIT 10"

  • confirmed: set to true to acknowledge the raw query (currently informational)

Behavioral notes:

  • ONLY SELECT statements are allowed. INSERT, UPDATE, DELETE, DROP, ALTER, CREATE, GRANT, and other DDL/DML are rejected.

  • The LIMIT clause is mandatory — queries without LIMIT are rejected.

  • Only single-statement queries are allowed (no semicolons separating multiple statements).

  • Dangerous functions (pg_read_file, COPY, pg_sleep, etc.) are blocked.

  • Results are capped at 5000 rows to prevent memory exhaustion.

  • Sensitive columns are automatically redacted in the output.

  • For write operations, use the structured tools (db_create, db_update_many, etc.).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYesRaw SQL statement. SELECT (must end with LIMIT) by default; non-SELECT requires confirmed: true, ALLOW_RAW_WRITES on the server, and a server that is not read-only
databaseNoName of the database to query (from pgautopilot.json). Omit to use the current default database.
confirmedNoExplicit user confirmation to allow a single non-SELECT (write/DDL) statement
Install Server

TDQS

A4.9/5.0
Behavior5/5

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

The description goes far beyond the annotations by disclosing the read-only transaction, timeout default, mandatory LIMIT enforcement, single-statement restriction, blocked dangerous functions, 5000-row cap, and column redaction. It is consistent with readOnlyHint=true and destructiveHint=false. One caveat: the schema's sql/confirmed descriptions imply non-SELECT writes are possible, which conflicts with this description; however, the description itself is transparent and aligned with the annotations.

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?

The description is longer than average, but the length is justified for a raw SQL tool with safety implications. It is well-structured with clear sections. A small redundancy exists between the intro's list of complex query types and the 'When to use' bullets, but the overall organization makes it easy to scan.

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?

For a complex, no-output-schema tool, the description covers essentially everything an agent needs: what queries are allowed, safety constraints, timeouts, result caps, redaction, and where to route write operations. The absence of an output schema is mitigated by describing result limitations and redaction.

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?

Schema coverage is 100%, and the description adds meaningful guidance beyond it: a complete SQL example, the mandatory LIMIT rule, and clarification that confirmed is currently informational. The database parameter is adequately covered by the schema, so no further description is needed.

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 states the specific verb ('Executes'), the resource ('raw SQL SELECT statement'), and the defining constraint ('mandatory LIMIT clause'). It also clearly frames the tool as an 'escape hatch' for queries that structured tools cannot express, distinguishing it from siblings like db_find_many and db_aggregate.

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?

The 'When to use' section explicitly lists complex JOINs, CTEs, window functions, subqueries, and custom aggregations. It also provides clear exclusions: write operations should use structured tools like db_create and db_update_many. This gives an agent concrete routing criteria.

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

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/cyberreinxy/pgautopilot'

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