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

Analyze session cost

analyze_session_cost
Read-only

Analyze PostgreSQL audit events to flag hot repeated tool calls, redundant listing calls, and idle sessions, then suggest caching or schema-compaction fixes.

Instructions

Surface hot-path inefficiencies from the audit log. Reads mcpg_audit.events over the last lookback_minutes (default 60, capped at 1440) and flags tools called more than hot_threshold times (default 10). Catalogue-listing tools (list_tables / list_schemas / list_indexes / etc.) get a redundant_listing finding pointing at get_compact_schema; other tools get a hot_repeated_call finding suggesting caching. Idle sessions get an idle_session finding. When mcpg_audit.events doesn't exist (audit subsystem off) returns audit_table_present=False with a diagnostic. Returns an object with audit_table_present (bool), events_examined (int), lookback_minutes, findings (list of objects with reason, tool, call_count, suggestion), and detail.

Example: analyze_session_cost(lookback_minutes=30, hot_threshold=15)

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

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.
hot_thresholdNo
lookback_minutesNo

Output Schema

NameRequiredDescriptionDefault
detailNo
findingsYes
events_examinedYes
lookback_minutesYes
audit_table_presentYes

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.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 adds real value on top: the data source, the 1440-minute cap on lookback, the default thresholds, and the specific finding taxonomy (redundant_listing, hot_repeated_call, idle_session). It also discloses graceful degradation to audit_table_present=False when the audit table is absent, which is exactly the kind of behavioral trait annotations cannot express. However, it never states cost or volume characteristics — e.g. how expensive scanning a 1440-minute window is, or whether results are sampled — leaving the agent without a sense of call risk on large windows.

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 the core action and source, then layers thresholds, finding types, and the failure mode in a logical order, closing with a concrete call example. It is dense but each clause carries information; the one redundancy is restating the return object shape, which the output schema already defines.

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?

Given an output schema exists, the description need not enumerate return fields, yet it does — a minor duplication rather than a harm. Everything an agent needs to invoke it correctly is present: source table, both tunable thresholds with defaults and a cap, finding semantics, and the no-audit-table diagnostic path. The only real omission is the role of the `database` parameter for this read path.

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

Parameters4/5

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

Schema coverage is only 33% (only `database` is documented in-schema), so the description must carry the rest — and it does, giving defaults for `lookback_minutes` (60) and `hot_threshold` (10) plus the 1440 cap that the schema does not express. The `database` parameter is not mentioned at all in the description, so it is unclear whether the audit events are read from the primary or the selected secondary, which is a meaningful gap for a multi-database tool.

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 opens with a specific verb and resource — "Surface hot-path inefficiencies from the audit log" — then names the exact source table (mcpg_audit.events) and the finding categories produced. It is clearly distinguishable from siblings like list_audit_events (raw events) or analyze_workload (query workload), since it is scoped to per-tool call counts and redundant catalogue listings.

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?

It gives clear triggering context (analyzing audit-log call patterns with configurable lookback and hot threshold) and even routes the agent onward via the 'suggestion' field (get_compact_schema for redundant listings). It does not explicitly say when to prefer this over analyze_workload or list_audit_events, nor state prerequisites such as the audit subsystem needing to be enabled — only the degradation behavior is described.

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