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 PG search maintenance

recommend_pg_search_maintenance
Read-only

Audit pg_search BM25 indexes for missing key_field and unset field configs, returning advisor findings with ready-to-run SQL fixes.

Instructions

Walk every pg_search BM25 index and emit advisor findings. Rules currently surfaced: missing_key_field (CRITICAL — the key_field reloption is required by upstream; an index without it can't satisfy queries) and no_field_configs (WARNING — none of the six *_fields reloptions are set, so the index falls back to default tokenization for every indexed column). Each finding carries a ready-to-run suggested_action SQL statement. Returns an empty list when the extension is not installed. Also feeds the pg_search BM25 Indexes category in audit_database.

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_pg_search_maintenance"
  }
}

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
resultYes

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

A3.9/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds substantive behavior beyond that: the enumerated rules with their severities and rationale, the fact that each finding includes a ready-to-run suggested_action SQL statement, and the edge case that an empty list is returned when the extension is absent. That is meaningful disclosure for a read-only advisor.

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?

Front-loaded with the core action, then structured parenthetical rule explanations, then return behavior and cross-reference. Dense but every clause carries information; a minor trim of the verbose severity explanations would help but nothing is truly wasteful.

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, the description needn't explain the return shape, yet it still discloses the finding structure and the empty-list case. Combined with the rule catalog, an agent has enough to call and interpret this correctly; only explicit alternative-comparison guidance 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 description coverage is 100% and the single database parameter is already fully documented in the schema (optional, list_databases ids only, secondaries rejected). The description adds nothing about the parameter, so the baseline 3 applies.

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?

Opens with a specific verb and resource: 'Walk every pg_search BM25 index and emit advisor findings,' which is unmistakably distinct from siblings like recommend_turboquant_maintenance or recommend_hnsw_ef_search. Naming the exact rule identifiers (missing_key_field, no_field_configs) makes the scope concrete rather than generic.

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 resource-specific phrasing and by the note that it feeds the 'pg_search BM25 Indexes' category in audit_database, which hints at a relationship to that sibling. However, there is no explicit when-to-use/when-not-to-use guidance, no mention of prerequisites such as the extension needing to be installed beyond the empty-list behavior, and no pointer to an alternative tool.

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