postgres-mcp

Overview Schema Source Related Servers Discussions Admin

query

Read-only

Execute read-only SQL against PostgreSQL with automatic policy validation, allowlist checks, and enforced row limits. Returns rows as JSON.

Instructions

Run a read-only SQL query against the database.

The query is validated against the security policy before execution: only allowlisted commands are accepted, denied keywords are rejected, and a LIMIT is appended automatically when the query has none.

Args: sql: SQL statement to execute (read-only).

Returns: Rows as a JSON array of objects, or an object with an "error" key.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sql": "<sql>"
    },
    "name": "query"
  }
}

Input Schema

Name	Required	Description	Default
`sql`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 12, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description had a lower bar, yet it adds substantive behavior: pre-execution validation against a security policy, allowlist/denylist keyword handling, and automatic LIMIT appending. Those are non-obvious operational traits that materially affect how an agent should write SQL.

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?

Front-loaded with the core action and the security/validation behavior in a tight three-sentence block. The Args/Returns sections are mild boilerplate, and the Returns prose is partly redundant given an output schema exists, but nothing is bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-param read-only query tool with an output schema, the description covers the action, the security/validation behavior, and the error-shape at a high level. The remaining gap is routing guidance against sibling schema-inspection tools, which would make it fully self-sufficient.

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

Parameters3/5

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

Schema description coverage is 0% for the single parameter, so the schema itself gives no semantics. The description only restates 'sql: SQL statement to execute (read-only)', adding just the read-only constraint; it does not clarify dialect, expected syntax, or LIMIT interaction beyond the general policy note. Minimum viable.

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

Purpose4/5

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

States a specific verb+resource ('Run a read-only SQL query against the database') and the read-only scope, which clearly separates it from the DDL-ish siblings. It never explicitly contrasts itself with list_tables/describe_table/relationships, so sibling differentiation is left implicit rather than stated.

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

Usage Guidelines3/5

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

Usage is implied by the 'read-only SQL query' framing, but there is no explicit when-to-use/when-not guidance and no mention of when an agent should reach for describe_table or list_tables instead. Adequate but with a clear gap.

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

Deploy Server