Skip to main content
Glama
devopam

MCPg - Production-grade PostgreSQL MCP Server

List autowarm jobs

list_autowarm_jobs
Read-only

Lists all pg_cron autowarm jobs registered by MCPg, returning job ID, name, cron schedule, and SQL command. Returns empty when pg_cron is not installed.

Instructions

List the pg_cron jobs MCPg registered for autowarm (jobname LIKE 'mcpg_autowarm%'). Returns an empty list when pg_cron is not installed. Returns a list of objects with jobid, jobname, schedule (the cron expression), and command (the SELECT the job runs).

Example: list_autowarm_jobs()

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
databaseNoOptional: target a configured secondary (read-only) database by name; omit for the primary. Call list_databases to see the configured ids.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Description adds value beyond annotations by explaining the return empty list when pg_cron is missing and detailing the exact structure of returned objects (jobid, jobname, schedule, command). No contradiction with readOnlyHint annotation.

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?

Description is clear and front-loaded with purpose. The example is helpful, though could be considered slightly redundant; overall efficient.

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 list tool with complete schema, annotations, and output description in the text, the description is fully adequate. It covers behavior when pg_cron is missing and result fields.

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% with the database parameter already described. The description provides an example call without arguments, but does not add new meaning beyond the schema. Baseline 3 is appropriate.

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 clearly states the tool lists pg_cron jobs registered for autowarm with a specific filter condition (jobname LIKE 'mcpg_autowarm%'). It distinguishes from sibling list_cron_jobs by its scope, providing specific verb and resource.

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 context is clear: it returns autowarm jobs and empty list if pg_cron not installed. However, it does not explicitly mention when not to use it or point to alternatives like list_cron_jobs for broader listings.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/devopam/MCPg'

If you have feedback or need assistance with the MCP directory API, please join our Discord server