Skip to main content
Glama
milad-codes

pg-readonly-mcp

by milad-codes

Explain a query

explain_query
Read-onlyIdempotent

Shows the PostgreSQL execution plan for a SELECT query with node types, scans, and index suggestions; optionally executes it for real timings when enabled.

Instructions

Shows the PostgreSQL execution plan of a SELECT with a summary (node types, sequential scans, index suggestions). analyze=true executes the query and is only available if the server enables it.

Input Schema

NameRequiredDescriptionDefault
sqlYes
paramsNo
analyzeNoExecute the query to get actual timings (if enabled)

Output Schema

NameRequiredDescriptionDefault
planYes
summaryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds context annotations cannot: that analyze=true actually executes the query and that this mode is gated by server configuration. Minor gap: no statement about cost/runtime risk of executing the query or side effects beyond the SELECT restriction.

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?

Two sentences, zero filler, with the core behavior front-loaded and the risky analyze mode called out afterward. Every clause earns its place.

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?

An output schema exists, so return values needn't be detailed, and the description still sketches what the summary contains. The remaining shortfall is the undocumented params array and the absence of any statement about what the explain output looks like beyond node types.

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 coverage is only 33% - sql and params carry no schema descriptions at all. The description compensates partially by constraining sql to a SELECT and explaining analyze=true. But the params array (bind parameters for the query) is never mentioned, leaving a meaningful gap.

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?

Specific verb and resource: shows the PostgreSQL execution plan of a SELECT, and even enumerates what the summary contains (node types, sequential scans, index suggestions). It is distinguishable from run_query by being an explain operation rather than an execution, but it never names the sibling to make that contrast explicit.

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 purpose (use it to inspect a plan) and there is a useful conditional on analyze=true ('only available if the server enables it'). However, there is no explicit guidance on when to pick this over run_query, or on prerequisites such as whether the statement must be a single SELECT.

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