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

Why is this slow

why_is_this_slow
Read-only

Diagnose slow SQL queries by running EXPLAIN without executing them, inspecting plans, contention, and cache stats, then returning categorized tuning suggestions.

Instructions

Diagnose why a SQL query might be slow, in one call. Runs EXPLAIN (FORMAT JSON) — does NOT execute the query — walks the plan tree, snapshots concurrent active queries + blocking lock pairs, reads the cluster-wide cache hit ratio, and produces categorised suggestions (plan / contention / cache / maintenance). Read-only; safe to run on a statement the agent doesn't want to materialise yet.

Example: why_is_this_slow(sql='SELECT * FROM orders WHERE customer_id = 42')

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": "why_is_this_slow"
  }
}

Input Schema

NameRequiredDescriptionDefault
sqlYes
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.

Output Schema

NameRequiredDescriptionDefault
sqlYes
suggestionsYes
explain_planYes
plan_summaryYes
active_queriesYes
blocking_locksYes
cache_hit_ratioYes

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?

Annotations only declare readOnlyHint/openWorldHint; the description goes much further by disclosing the diagnostics it bundles (plan tree walk, concurrent active queries, blocking lock pairs, cluster-wide cache hit ratio) and the fact that it does no write or execution. Crucially it explains WHY it is read-only — EXPLAIN without ANALYZE — which is the non-obvious safety detail an agent needs.

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 opening clause is front-loaded with the core capability and the no-execution guarantee follows immediately; the example anchors the call format. The middle sentence is dense with a comma-list of diagnostics, which is efficient but slightly overloaded for a single sentence.

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

Completeness5/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 structure needn't be spelled out, yet the description still tells the agent what categories of findings come back (plan / contention / cache / maintenance). Combined with the safety disclosure and example, nothing needed to invoke it correctly is missing.

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 50%: `database` is well documented in the schema (targeting configured secondary databases via list_databases), while `sql` has none. The example shows the shape of the SQL argument, which helps slightly, but the description adds no semantics about database targeting or SQL statement constraints. Baseline 3 applies since the schema does most of the work.

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 outcome ("Diagnose why a SQL query might be slow") and immediately pins down the mechanism (EXPLAIN FORMAT JSON, no execution). The scope is concrete enough to separate it from read/execute tools like run_select and from pure plan viewers like explain_query.

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 a clear when-to-use signal: for a statement the agent doesn't want to materialise yet, and the no-execution guarantee makes the safe-use context explicit. It stops short of naming alternatives (explain_query, analyze_query_plan, run_select) or stating exclusions, so the agent must infer routing from neighbouring tool names.

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