MCPg - Production-grade PostgreSQL MCP Server

Overview Schema Source Related Servers Discussions Admin

Get PG search index metadata

get_pg_search_index_metadata

Read-only

Fetch typed reloptions and raw metadata for a single BM25 index to inspect its configuration without parsing reloptions manually.

Instructions

Fetch the parsed reloptions for a single BM25 index (schema.index). Same shape as one entry of list_pg_search_indexes — typed accessors for the 13 documented options plus the raw index_options dict. Raises when the extension is not installed or no BM25 index by that name exists. Returns an object with schema, index, the typed option fields, and index_options (raw reloptions dict for forward-compat).

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": {
      "schema": "<schema>",
      "index": "<index>"
    },
    "name": "get_pg_search_index_metadata"
  }
}

Input Schema

Name	Required	Description
`index`	Yes
`schema`	Yes
`database`	No	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.

Output Schema

Name	Required	Description	Default
`index`	Yes
`table`	Yes
`schema`	Yes
`columns`	Yes
`sort_by`	No
`key_field`	No
`json_fields`	Yes
`layer_sizes`	No
`text_fields`	Yes
`range_fields`	Yes
`index_options`	Yes
`boolean_fields`	Yes
`numeric_fields`	Yes
`datetime_fields`	Yes
`search_tokenizer`	Yes
`mutable_segment_rows`	No
`target_segment_count`	No
`background_layer_sizes`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.8.4Nov 5, 2026

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."

First observedv0.6.8Jul 6, 2026

TDQS

A4.1/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 adds genuinely new behavior: it raises when the pg_search extension is absent or the named index does not exist, and it exposes a raw index_options dict for forward compatibility. The return-shape sentence overlaps with the output schema, but the failure modes are valuable.

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 first sentence carries the core purpose and is front-loaded; the rest is compact. The closing sentence restating the return object is largely redundant given the output schema, so a little space is not earned.

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?

For a two-key read-only lookup with an output schema, this covers purpose, error conditions, and output shape. Secondary-database targeting is left entirely to the single schema description, but overall an agent has enough to call it correctly.

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 only 33% — just the optional database parameter is documented in the schema. The description partially compensates by framing schema and index as a composite identifier pair, but it does not clarify identifier casing, quoting, or what database targeting changes beyond what the schema already says.

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 — fetch parsed reloptions for a single BM25 index — and names the composite key form (schema.index). It also distinguishes itself from list_pg_search_indexes by noting the output is the same shape as one of its entries.

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?

The reference to list_pg_search_indexes implies the split: enumerate with that tool, drill into one with this one. It also gives a precondition (raises if the extension is not installed or no BM25 index by that name exists), but it never explicitly says 'use this instead of X when...'.

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

Deploy Server