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

Recommend IO method

recommend_io_method
Read-only

Recommends a PostgreSQL 19 io_method (sync, worker, or io_uring) from workload read/cache stats and returns ready-to-run SQL when a setting change is advised.

Instructions

Recommend a PG 19 io_method ('sync' / 'worker' / 'io_uring') for the current workload. Reads pg_stat_database aggregates (blks_read / blks_hit / stats_reset) and the current setting, then maps the workload signals to one of: high_concurrent_read_load (→ io_uring), bursty_io_with_cache_pressure (→ worker), low_io_pressure (→ sync), current_setting_optimal (no change), or insufficient_stats (window too short). Read-only — never invokes ALTER SYSTEM; emits a ready_to_run_sql snippet the operator can paste when the recommendation differs from the current setting. Returns an object with available (bool), server_version_num, detail, and recommendations — a list of objects with recommended_method, reason, current_method, cache_miss_ratio, reads_per_second, stats_window_seconds, and ready_to_run_sql (null when no change suggested).

Example: recommend_io_method()

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

Input Schema

NameRequiredDescriptionDefault
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
detailYes
availableYes
recommendationsYes
server_version_numYes

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 already declare readOnlyHint=true and openWorldHint=false, and the description reinforces this by stating it never invokes ALTER SYSTEM and only emits a pasteable ready_to_run_sql snippet. It also discloses the insufficient-stats failure mode and the cache-miss/read-rate signals used. It does not discuss permissions or cost of reading the stats views.

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 the data sources, then the enumerated outcome labels, then the side-effect guarantee and return shape. Dense but every clause carries decision-relevant information; the trailing example call is the only filler.

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 100% schema coverage, the definition covers what an agent needs: scope, inputs, decision outputs, and no-write guarantee. The only omission is how the optional `database` target interacts with secondary/read-only databases in terms of stats availability.

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?

The single `database` parameter is documented at 100% coverage in the schema, including its list_databases id constraint, and the description adds nothing about it (it only shows a zero-arg example call). Baseline 3 applies when the schema carries the parameter semantics.

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 ('Recommend a PG 19 io_method') and enumerates the exact candidate values and the signal-to-outcome mapping the tool produces. An agent can distinguish it from recommend_postgres_conf, inspect_guc, or get_aio_status without opening schemas, since this one is scoped to io_method selection.

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 clear context for use: it reads pg_stat_database aggregates plus the current setting and requires an adequate stats window (with 'insufficient_stats' handled explicitly). It does not explicitly name alternative tools or say when to prefer them, so it stops short of full when/when-not guidance.

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