Skip to main content
Glama

Explain Query Plan

db_explain
Read-onlyIdempotent

Run EXPLAIN ANALYZE on SELECT queries to inspect execution plans, timing, and buffers, revealing bottlenecks and missing index opportunities.

Instructions

Runs EXPLAIN ANALYZE on a SQL SELECT query to analyze its execution plan, performance characteristics, and bottlenecks. Returns the full execution plan with timing, buffer usage, row estimates, and actionable analysis. This tool helps you understand how PostgreSQL processes a query and identifies optimization opportunities like missing indexes, sequential scans, or high-cost operations.

When to use:

  • "Why is this query slow?"

  • "Help me optimize this query"

  • "What indexes would improve this query?"

  • Before creating indexes, to understand current plan

Parameter guidance:

  • query: the SQL SELECT query to analyze (required). Example: "SELECT u.name, COUNT(o.id) FROM users u JOIN orders o ON o.user_id = u.id WHERE o.created_at > '2025-01-01' GROUP BY u.name ORDER BY COUNT(o.id) DESC LIMIT 10"

  • analyze: set to true for actual timing (default: true)

  • buffers: set to true to include buffer usage stats (default: true)

Behavioral notes:

  • Only SELECT queries are accepted — EXPLAIN on writes is not supported.

  • The query is NOT executed — only the plan is analyzed.

  • Results include: execution plan (JSON), total cost, actual time, rows, buffers, and analysis text.

  • Analysis highlights: sequential scans on large tables, low selectivity filters, missing index opportunities, high-cost joins.

  • No extensions required — uses built-in PostgreSQL EXPLAIN.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesThe SQL SELECT query to analyze. Must be a SELECT statement. The query is wrapped in EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) automatically.
analyzeNoRun EXPLAIN ANALYZE for actual timing (default: true).
buffersNoInclude buffer usage statistics (default: true).
databaseNoName of the database to query (from pgautopilot.json). Omit to use the current default database.
Install Server

TDQS

A4.5/5.0
Behavior4/5

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

The description adds substantial behavioral context beyond annotations: only SELECT is accepted, query has no persistent side effects, output includes execution plan JSON/cost/time/buffers/analysis, and no extensions are required. Minor imprecision: 'The query is NOT executed' is technically misleading for EXPLAIN ANALYZE, which executes internally to gather timing.

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?

The description is longer than average but strictly organized into overview, when-to-use, parameter guidance, and behavioral notes. Every section carries necessary information, and there is no filler or redundancy beyond the minor execution phrasing.

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?

For a 4-parameter tool with no output schema, this is complete: it covers invocation, parameter format, behavioral limits, result contents, analysis focus, and prerequisites. An agent has enough to decide when to call it and what to expect.

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

Parameters4/5

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

Schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds value with a full example query, clarifies the effect of analyze/buffers defaults, and lists result components. The database parameter is not elaborated, but the schema covers it adequately.

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 first sentence names a specific action ('Runs EXPLAIN ANALYZE') and resource ('SQL SELECT query'), and the rest specifies the output (execution plan, performance characteristics, bottlenecks). It is clearly differentiated from sibling row-returning tools (db_find_many, db_raw_query) by being explicitly about query plan analysis.

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?

A dedicated 'When to use' section lists four concrete scenarios, from 'Why is this query slow?' to 'Before creating indexes'. No explicit when-not-to-use or alternative tool names are given, so it stops short of a full 5.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cyberreinxy/pgautopilot'

If you have feedback or need assistance with the MCP directory API, please join our Discord server