Skip to main content
Glama
Sign In
MCPg - Production-grade PostgreSQL MCP Server

MCPg - Production-grade PostgreSQL MCP Server

by devopam
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Run SELECT parallel

run_select_parallel
Read-only

Execute multiple read-only SELECT statements concurrently with per-query safety validation and isolated error outcomes, so dashboard fan-out queries return indexed results even if one query fails.

Instructions

Run up to parallel_limit read-only SELECTs concurrently. Each statement is validated by the same safety allowlist as run_select; one bad query does not abort the others — its error is captured in its own outcome slot. Useful for dashboard-style fan-out where round-trip latency dominates (e.g. fetching counters / aggregates from several tables at once). Each outcome includes an index so the caller can correlate results without relying on ordering.

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": {
      "statements": "<statements>"
    },
    "name": "run_select_parallel"
  }
}

Input Schema

NameRequiredDescriptionDefault
databaseNoOptional: a database id from list_databases, to target a configured secondary (read-only) database; omit for the primary. Database names that are not configured ids are rejected.
max_rowsNo
statementsYes
parallel_limitNo

Output Schema

NameRequiredDescriptionDefault
outcomesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.4
    • changedInput schema / properties / database / description
      Previous value: -"Optional: target a configured secondary (read-only) database by name; omit for the primary. Call list_databases to see the configured ids."New value: +"Optional: a database id from list_databases, to target a configured secondary (read-only) database; omit for the primary. Database names that are not configured ids are rejected."
  2. First observedv0.6.8

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses the key behavioral traits of a fan-out tool: per-statement validation against the same safety allowlist, failure isolation ('one bad query does not abort the others — its error is captured in its own outcome slot'), and index-tagged outcomes enabling correlation without relying on ordering. These are exactly the partial-failure semantics an agent needs before batching.

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?

Three sentences, each carrying distinct load: capability, error-isolation contract, and result-correlation mechanism. The limitation is stated up front and nothing is repeated from the title or annotations.

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?

The tool is moderately complex (4 params, 1 required, output schema present), and the description covers concurrency semantics, failure handling, and result correlation well enough to call it correctly. The only real gap is the undocumented `max_rows` row-cap behavior, which matters when fanning out over large tables.

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 25% — only `database` is documented in the schema. The description compensates by explaining `parallel_limit` (cap on concurrent statements) and the semantics of `statements` (each validated individually with per-slot errors), but `max_rows` is left entirely unexplained in both places, so the coverage gap is only partly closed.

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 opens with a specific verb and resource: 'Run up to parallel_limit read-only SELECTs concurrently.' It also implicitly differentiates itself from the sibling run_select by naming it in the allowlist comparison, so an agent can tell the batched variant apart from the single-statement one.

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?

It gives a clear use case ('dashboard-style fan-out where round-trip latency dominates, e.g. fetching counters/aggregates from several tables at once') and references run_select as the shared-safety single-query counterpart. It never states explicitly when to prefer run_select over this tool for a single statement, so the routing guidance is contextual rather than exhaustive.

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

Deploy Server

Other Tools