Skip to main content
Glama
AkshaySwami14

pg-schema-scout

run_query

Read-onlyIdempotent

Execute read-only SQL queries to fetch PostgreSQL rows, blocking writes and returning result sets.

Instructions

Execute a read-only SELECT and return the rows.

Use this once you know which tables and columns you need. If you do not yet know, call search_schema first rather than guessing table names; a query against a table that does not exist wastes a round trip.

Only a single SELECT is accepted. WITH is fine as long as the whole statement is read-only. Anything else, including INSERT/UPDATE/DELETE, DDL, statement stacking, and DML hidden inside a CTE, is rejected before it reaches the database.

On failure:

  • "Blocked: ..." means the statement violated the read-only policy. The message names the offending construct. Rewrite as a plain SELECT; do not retry the same statement.

  • A syntax or "column does not exist" error means the schema assumption was wrong. Call describe_table on the table in question and correct the column names rather than guessing again.

  • A statement timeout means the query was too expensive. Call explain_query to see the plan, then add a WHERE clause or aggregate.

Results are capped. When truncated is true the rows shown are a prefix, not the answer; narrow the query instead of treating them as complete.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYes
max_rowsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoSet when truncated, explaining how to narrow the query.
rowsYesRow-major values, aligned with columns.
columnsYes
row_countYesNumber of rows returned, after any truncation.
truncatedYesTrue when the result hit max_rows and more rows exist.
Behavior5/5

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

Discloses read-only policy enforcement details: only single SELECT accepted, rejects DML/DDL/stacking (including DML in CTEs), with error prefix 'Blocked: ...' explained. Also discloses result capping and the meaning of the truncated flag—all beyond the readOnlyHint and idempotentHint annotations.

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?

Well-structured with a clear opening purpose and organized failure/recovery sections. Every sentence adds operational value; no filler or redundancy. Length is justified by the number of constraints and failure modes.

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?

Covers purpose, usage timing, policy restrictions, failure remediation, and output limits. With an output schema present, return values need no further description. The description is sufficiently complete for the agent to select and invoke correctly.

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 provides no descriptions (0% coverage). The description thoroughly explains the sql parameter: must be a read-only SELECT, single statement, WITH allowed. However, max_rows is only indirectly addressed via result capping/truncation; it doesn't explicitly state that max_rows controls the cap. Still, it adds substantial meaning for the required parameter.

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 specifically: 'Execute a read-only SELECT and return the rows.' This clearly conveys the verb (execute), resource (SQL SELECT), and output (rows). It differentiates from sibling search_schema (schema discovery), describe_table (schema details), and explain_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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs: 'Use this once you know which tables and columns you need. If you do not yet know, call search_schema first rather than guessing table names.' Also provides fallback guidance to call describe_table after schema errors and explain_query after timeouts, making alternatives and exclusions explicit.

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

Install Server

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/AkshaySwami14/pg-schema-scout'

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