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

Detect n plus one

detect_n_plus_one
Read-only

Identify likely N+1 query loops in pg_stat_statements by surfacing high-call templates returning few rows with meaningful total time, sorted by total time so worst candidates appear first.

Instructions

Surface query templates in pg_stat_statements that look like an N+1 loop: hundreds of calls, each returning at most a row or two, with meaningful total wall-clock time spent. Returns the candidates sorted by total time descending so the worst offender appears first. Thresholds (min_calls, max_rows_per_call, min_total_ms) are tunable. Treat results as candidates for investigation, NOT verdicts — a hot cache-miss pattern on a primary-key lookup can trip the same shape. Reports availability=false if pg_stat_statements is not installed.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "detect_n_plus_one"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
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.
min_callsNo
min_total_msNo
max_rows_per_callNo

Output Schema

NameRequiredDescriptionDefault
availableYes
candidatesYes
thresholdsYes

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.2/5.0
Behavior4/5

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

Annotations cover read-only/local behavior, and the description adds real value beyond them: result ordering (total time descending), the availability=false signal when pg_stat_statements is not installed, and the caveat about interpretation. It does not mention auth requirements or cost/latency of the scan itself, but it is well above the annotation floor.

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 with the purpose, then ordering, then tuning knobs, then the interpretation caveat and failure mode. Each sentence carries distinct information with no filler or repetition.

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?

With an output schema present and read-only annotations supplied, the description covers what is needed to call and interpret the tool: purpose, ordering, tunables, caveat, and extension-absent behavior. The only real gap is that `limit` and the precise threshold semantics are left to a sparse schema.

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 only 20% (only `database` is documented), so the description has to compensate. It does name the three tunable thresholds (min_calls, max_rows_per_call, min_total_ms) and implies their meaning through the N+1 shape description, but it never explains `limit` or states defaults/exact semantics for the thresholds. Partial compensation only.

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?

States a specific verb and resource ('Surface query templates in pg_stat_statements that look like an N+1 loop') plus the exact detection shape (hundreds of calls, one or two rows each, meaningful wall-clock time). That is clearly distinct from siblings like recommend_indexes, analyze_workload, or why_is_this_slow, which are broader diagnostics.

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?

Gives strong usage context: results are candidates for investigation, not verdicts, and it names the false-positive shape (hot cache-miss on a primary-key lookup). It also states the failure mode when pg_stat_statements is absent. It stops short of naming a specific alternative tool to run instead when the result set is noisy or when the extension is missing.

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