Loading ToolBench
A professional MCP server for PostgreSQL database server operations, monitoring, and management with query performance monitoring, database/table/user listing, configuration status, connection information, and index usage statistics.
Two tools present with explicit registration via @mcp.tool() decorators in mcp_main.py. Both are READ_ONLY database monitoring operations. Tool descriptions are present and substantive (120-180 chars each), meeting baseline expectations. However, critical gaps exist: (1) Input schema for get_lock_monitoring is fully specified with 6 filter parameters, all with type and description, but for get_wal_status the input schema is empty ({}), violating the rule that every parameter needs description. (2) Output schemas are completely undocumented, the rubric requires documenting return structures so LLMs know what fields to expect. No return type hints visible in the code sample. (3) Parameter descriptions are present for get_lock_monitoring but lack format constraints and enum declarations (e.g., 'granted' accepts 'true'/'false' as strings, should be an enum; 'mode' lists examples but no enum). (4) Error handling is not visible in the provided code, no indication of how invalid filters or connection failures are communicated to the LLM. (5) Tool names are verb-forward ('get_lock_monitoring', 'get_wal_status') and unambiguous, meeting naming baseline. The server is functional for basic read-only monitoring but lacks production polish on parameter validation and output structuring.
Monitor current locks and potential deadlocks in PostgreSQL. List all current locks held and waited for by sessions. Show blocked and blocking sessions, lock types, and wait status. Help diagnose lock contention and deadlock risk. Filter results by granted status, state, mode, lock type, or username.
Monitor WAL (Write Ahead Log) status and statistics. Show current WAL location and LSN information. Display WAL file generation rate and size statistics. Monitor WAL archiving status and lag. Provide WAL-related configuration and activity metrics.
get_wal_status has empty input schema ({}). The rubric requires every parameter to have type and description; empty schema violates this and prevents the LLM from understanding what the tool accepts.
Output schemas undocumented for both tools. The rubric requires documenting return structures (fields, types, example response shape) so LLMs can plan downstream calls and extract relevant data. Currently LLMs have no visibility into what get_lock_monitoring or get_wal_status return.
Parameter 'granted' in get_lock_monitoring is documented as accepting 'true' or 'false' (string values) but not declared as an enum. Similarly, 'mode' lists examples ('AccessShareLock', 'ExclusiveLock') but not as enum. Enums are self-documenting and prevent LLMs from hallucinating invalid values.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No error handling guidance visible in code sample. The rubric requires error responses to tell LLMs what to do next (retry guidance, alternative tools, self-correction hints). No evidence of try-catch, validation, or actionable error messages.
Parameter descriptions lack format/range constraints. E.g., 'username' has no guidance on length, special characters, or case sensitivity. 'database_name' lacks explanation of fallback behavior ('uses default database if omitted'). Constraints should be explicit in descriptions, not just in docstrings.
No pagination parameters visible for get_lock_monitoring (which could return hundreds of locks). The rubric requires list/offset and limit parameters plus total count for large result sets to avoid context window exhaustion.