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

Get current WAL LSN

get_current_wal_lsn
Read-only

Captures the current WAL LSN on a primary or standby so you can pass it to wait_for_lsn and ensure read-your-writes consistency before follow-up reads.

Instructions

Return the current WAL LSN — write-side on a primary (pg_current_wal_lsn()) or replay-side on a standby (pg_last_wal_replay_lsn()). Natural pairing for the read-your-writes workflow: capture on the primary right after a write, then pass to wait_for_lsn on the standby session before the follow-up read. Works on every supported PG version. Returns an object with role ('primary' or 'standby') and lsn (PostgreSQL LSN literal, e.g. '0/1234ABCD').

Example: get_current_wal_lsn()

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

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
lsnYes
roleYes

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, so safety is covered; the description adds real value beyond that by disclosing role-dependent behavior (different PG function on primary vs standby) and version portability across supported PG versions. It also describes the returned object shape, though that partially duplicates the output schema.

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-loads purpose, then workflow, then compatibility, then return shape — a sensible ordering with little waste. The trailing 'Example: get_current_wal_lsn()' line earns almost nothing for a zero-required-argument tool and is the one removable sentence.

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 simple read tool, the description covers purpose, primary/standby semantics, the companion workflow, version support, and return values, while the input schema and output schema carry the parameter and return details. An agent has everything needed to call it correctly in the intended workflow.

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 100% and the single `database` parameter is fully documented in the schema, including the secondary/read-only targeting rule, so the baseline is 3. The description never mentions the parameter, adding no meaning on top of the schema.

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 ('Return the current WAL LSN') and immediately qualifies scope: write-side on a primary via pg_current_wal_lsn(), replay-side on a standby via pg_last_wal_replay_lsn(). This lets an agent distinguish it from adjacent tools like wait_for_lsn, read_pg_wal_stats, and get_wait_for_lsn_status without opening any schema.

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 concrete when-to-use guidance through the read-your-writes workflow: capture on the primary right after a write, then hand the value to wait_for_lsn on the standby before the follow-up read, and it names that sibling explicitly. What is missing is any when-not-to-use or exclusion (e.g. when get_wait_for_lsn_status or read_pg_wal_stats is the better call).

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