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

List locks

list_locks
Read-only

Inspect held and waiting PostgreSQL locks joined with pg_stat_activity backend state, including lock mode, relation, query snippet, and wait events; waiting locks appear first. Read-only.

Instructions

List currently-held and waiting locks, joined with backend state from pg_stat_activity. Ordered by (granted ASC, pid) so waiting locks float to the top. Returns lock type, mode, qualified relation name when applicable, transaction / virtualxid, the application_name + state + wait event of the owning backend, and the first 200 chars of its query. Read-only.

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

Input Schema

NameRequiredDescriptionDefault
limitNo
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

B3.1/5.0
Behavior3/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's 'Read-only' restates rather than extends that. It does add genuine behavior beyond structured fields: the (granted ASC, pid) ordering that floats waiting locks to the top, and the explicit column list of the result set. It omits pagination/truncation behavior and any cost or permission notes.

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?

Three tight sentences, front-loaded with what is listed, then ordering, then return shape; nothing is padded. The trailing 'Read-only' is redundant against the annotations but costs only a few words.

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 and annotations present, the description needn't restate return values, and it does supply the join source, sort order, and column intent. The remaining gap is the undocumented limit parameter and unspecified truncation behavior for the query snippet beyond 200 chars.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description says nothing about either parameter. Schema coverage is 50%: the database parameter is fully documented in the schema, but the limit parameter (default 100) has no description anywhere, so an agent gets no guidance on paging or how limit interacts with the ordering. The description fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('List currently-held and waiting locks') and states the join with pg_stat_activity, so the operation is unambiguous. It does not distinguish itself from near-siblings like read_pg_stat_lock, find_blocking_chains, or analyze_lock_hotspots, so an agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no explicit when-to-use guidance and no mention of alternatives, even though several siblings (find_blocking_chains, walk_blocking_chains, analyze_lock_hotspots, read_pg_stat_lock) cover adjacent territory. Usage is only implied by the fact that lock inspection is useful when diagnosing contention.

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