MCP PostgreSQL Operations

Overview Schema Source Related Servers Discussions Admin

get_running_vacuum_operations

Monitor currently running VACUUM, ANALYZE, and REINDEX operations to track progress, identify blocking or long-running maintenance, and troubleshoot stuck database tasks.

Instructions

[Tool Purpose]: Monitor currently running VACUUM and ANALYZE operations in real-time

[Exact Functionality]:

Show all currently active VACUUM, ANALYZE, and REINDEX operations
Display operation progress, elapsed time, and process details
Identify blocking or long-running maintenance operations
Provide process IDs for operation tracking

[Required Use Cases]:

When user requests "running VACUUM", "active maintenance", "current VACUUM status", etc.
When troubleshooting slow or stuck VACUUM operations
When monitoring maintenance operation progress
When identifying maintenance operations that may be affecting performance

[Strictly Prohibited Use Cases]:

Requests for terminating or controlling VACUUM processes
Requests for starting new VACUUM operations
Requests for changing VACUUM parameters or configuration

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

Input Schema

Name	Required	Description	Default
`database_name`	No	Target database name (shows operations in all databases if omitted)

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv3.4.3Oct 27, 2026
- addedInput schema / properties / database_name / description
```
Added value: +"Target database name (shows operations in all databases if omitted)"
```
Changed6 schema fields changedv3.4.2Oct 25, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedInput schema / properties / database_name / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedInput schema / properties / database_name / title
```
Removed value: -"Database Name"
```
- removedInput schema / properties / database_name / type
```
Removed value: -"string"
```
- removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
- removedOutput schema / title
```
Removed value: -"_WrappedResult"
```
Addedv1.0.0Jan 3, 2026

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the behavioral burden. It makes clear that this is a monitoring/read-oriented tool by stating that it shows and identifies running operations and explicitly prohibits starting, terminating, or changing VACUUM processes. It does not mention privilege requirements or potential monitoring overhead.

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 description is front-loaded with purpose and functionality, then use cases and exclusions. The bracketed section headers make it slightly verbose, but the structure is clear and each section contributes useful guidance.

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?

With an output schema present and full schema description coverage, the description does not need to explain return values or parameter details. It supplies the missing behavioral context by describing what is monitored, when to use it, and what it must not be used for.

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 optional database_name parameter is fully described in the schema. The description does not add filter syntax or behavior beyond the schema's note that omitting the database shows operations across all databases.

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?

The description states a specific monitoring action and resource: currently running VACUUM, ANALYZE, and REINDEX operations in real-time. The real-time, currently-active scope distinguishes it from sibling tools focused on historical vacuum/analyze statistics or autovacuum status.

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

Usage Guidelines5/5

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

It gives explicit trigger phrases and use cases such as checking running VACUUM, troubleshooting stuck operations, and monitoring progress. It also clearly lists prohibited use cases, including terminating, starting, or configuring VACUUM operations, which prevents misuse.

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

Deploy Server