Loading ToolBench
Production-grade MCP server for PostgreSQL with safety guardrails, schema intelligence, guarded writes, and audit logging
MCPBridge demonstrates solid tool design with clear naming, comprehensive descriptions, and proper schema definitions. All 9 tools follow verb_noun conventions (detect_anomalies, write_db, query_db, etc.). Descriptions average ~150 chars and explain WHAT, WHEN, and consequences. Input schemas use Zod with type annotations and descriptions. Tool annotations (readOnlyHint, destructiveHint) are present. However, output schemas are not formally documented in the code, responses are JSON strings without declared structure. The two-phase write pattern (write_db → confirm_write → reject_write) is well-designed for safety but lacks explicit idempotency guarantees. Error handling returns structured JSON but lacks recovery guidance in some cases.
Execute a write operation previously staged with write_db. Ask the user before confirming. High-risk operations additionally require acknowledge_risk=true.
Get detailed information about a table including columns, indexes, and foreign keys
Scan the recent audit trail for suspicious usage patterns: bursts of queries against one table, sequential id-enumeration scans, and activity during unusual hours.
Show the PostgreSQL execution plan for a read-only query without side effects. Set analyze=true to actually run the query and get real timings.
List all tables and views in the database schema
Execute a read-only SQL query (SELECT / WITH / SHOW) against PostgreSQL. Queries without a LIMIT are capped at configured max rows. Write statements are rejected — use write_db for those.
Output schemas not formally documented. Tools return JSON strings without declared response structure. LLMs cannot plan downstream calls or extract fields reliably without knowing what fields to expect.
search_data description mentions 'MCP sampling' but sampling is deprecated (removed from spec 2026-07-28). Tool should integrate directly with LLM provider API instead of relying on server-initiated sampling.
list_tables has minimal description (18 chars). Does not explain when to call it, what structure it reveals, or how it chains with describe_table. Should guide discovery workflow.
Error responses in code return errorResponse() but recovery guidance is not visible. Errors should tell LLM what to do next (retry, ask user, or fatal).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Cancel a write operation staged with write_db. No data is modified.
Answer a natural language question about the data. Uses MCP sampling to generate SQL, validates it through the same safety pipeline as query_db, executes it, and returns both the generated SQL and the results.
Stage an INSERT, UPDATE or DELETE for execution. The statement is NOT executed immediately: you get an impact preview and a confirmation_id, and must call confirm_write to execute (or reject_write to cancel). High-risk operations require acknowledge_risk=true on confirmation.
query_db accepts 'sql' parameter as free-form string with no validation hints in description. Should document: allowed statement types (SELECT/WITH/SHOW only), LIMIT enforcement, and what happens if LIMIT is omitted.