Skip to main content
Glama
abiswas97

Postgres MCP Server

by abiswas97

query

Execute parameterized SQL on PostgreSQL with pagination to retrieve controlled result sets.

Instructions

Execute SQL with pagination and parameterization

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYes
offsetNo
pageSizeNo
parametersNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It mentions pagination and parameterization, but says nothing about read/write semantics, transaction behavior, permissions, multiple-statement handling, or side effects. For an arbitrary SQL execution tool, these are significant undisclosed traits.

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 single sentence is front-loaded and contains no filler. It is efficient, though arguably too sparse for a tool with four parameters and no annotations. There is no wasted text.

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

Completeness2/5

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

Given the complexity of arbitrary SQL execution, four parameters, no annotations, and no output schema, the description is materially incomplete. It omits result format, error behavior, pagination defaults, parameter binding rules, and whether writes or DDL are permitted. It leaves an agent guessing on important invocation details.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but it only loosely references pagination and parameterization. It does not explain parameter binding order, how sql relates to parameters, default or maximum page sizes, or whether offset and pageSize interact. The required sql parameter is only implicitly covered by 'Execute SQL'.

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 and resource: 'Execute SQL'. This is clearer than a generic name like 'query' and distinguishes it from read-only siblings such as describe_table and list_schemas. It does not explicitly contrast with explain_query or list_objects, so sibling differentiation is not fully achieved.

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

Usage Guidelines2/5

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

The description gives no explicit when-to-use guidance, prerequisites, or alternatives. It implies that the tool runs SQL, but an agent gets no help deciding between this and explain_query, describe_table, or other sibling tools. There are also no exclusions or warnings about when not to use it.

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