Loading ToolBench
MCP server for DeepSQL CLI, DBA Agent (thin client), and stdio MCP server for self-hosted deployments. Provides database analysis, query optimization, and schema inspection tools.
This MCP server exhibits severe definition quality issues across nearly all 25 tools. While tool names follow verb_noun conventions (check_, analyze_, get_, find_, suggest_, generate_, etc.), the implementation lacks critical schema documentation, parameter descriptions, and output schema clarity. The server is written in TypeScript but the provided source code shows only Java backend service files and Dockerfile configurations, no actual MCP tool registration code is visible. This means tool definitions cannot be verified against the MCP protocol specification. Based on the supplied tool metadata (names and brief descriptions only), most tools have minimal parameter documentation and no visible output schemas. The database performance analysis tools (check_connection_count, analyze_slow_queries, etc.) have reasonable names but descriptions are generic and lack actionable guidance for LLM selection. Parameters like 'warning', 'critical', 'limit', 'min_duration_ms' lack detailed constraints, ranges, or format specifications. Agent-internal tools (context_resolution_tool, live_metadata_query_tool, metadata_context_resolution_tool) have vague descriptions and unclear composition boundaries. No evidence of error handling patterns, schema documentation, or recovery guidance is visible in the provided code snippets.
Analyze patterns in database connection usage over time
Analyze patterns in query execution to identify optimization opportunities
Analyze query execution plans for optimization opportunities
Analyze slow queries from the database slow query log
Check current connection count against max connections, calculate utilization percentage, and detect if warning or critical thresholds are exceeded
Check index usage statistics to identify unused or underutilized indexes
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract structured results when response schemas are invisible.
Most parameter descriptions are missing or trivial (single-word tool descriptions < 20 chars: 'Analyze slow queries from the database slow query log' is descriptive but most others like 'Analyze query execution plans for optimization opportunities' lack specifics on usage, constraints, and when to invoke).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | 2026-07-28+ | v2 |
Check for missing indexes that could improve query performance
Check for table bloat and unused space in tables (PostgreSQL only)
Resolve shared retrieval context for planned agent tasks using RAG and schema metadata
Detect potential connection leaks in the database connection pool
Generate EXPLAIN output for specified queries to show execution plans
Identify duplicate indexes that could be consolidated
Find missing indexes based on query analysis
Identify unused indexes that could potentially be dropped
Generate performance optimization recommendations based on analysis
Generate a summary of database performance findings
Retrieve currently active (non-idle) database queries with execution details
Retrieve detailed connection statistics and pool utilization
Retrieve queries that have been running longer than a specified duration threshold
Retrieve slow queries from the database slow query log with configurable duration threshold
Query live database metadata catalogs (performance_schema, information_schema, pg_catalog, pg_stat_*) when vault DB cached metadata is insufficient
Resolve metadata request scope for agent tasks based on question routing and schema context
Recommend optimal database connection pool size based on usage patterns
Scan and analyze all indexes in the database
Suggest indexes based on query patterns and missing index analysis
No numeric parameter constraints (min/max, valid ranges) visible. Parameters like 'limit' (default 20), 'min_duration_ms' (default 1000), 'warning' (default 80), 'critical' (default 95) lack documented bounds. LLMs may pass absurd values (limit=999999, min_duration_ms=-1, warning=200) that break execution or cause timeouts.
Tool naming clarity issue for agent-internal tools: 'context_resolution_tool', 'live_metadata_query_tool', and 'metadata_context_resolution_tool' use generic suffixes (_tool) and vague prefixes. They do not follow verb_noun convention (get_, resolve_, query_). Names should be 'resolve_context', 'query_live_metadata', 'resolve_metadata_scope' to clearly signal action.
No visible error handling patterns. Descriptions do not indicate what happens on failure (e.g., 'If query is invalid, returns an error. Try explain_queries with a simpler query.'), recovery actions, or error categorization (retryable vs user-fixable vs fatal).
Composition boundary unclear: analyze_slow_queries, get_slow_queries, and explain_queries have overlapping purposes. 'analyze_slow_queries' analyzes; 'get_slow_queries' retrieves; 'explain_queries' explains. LLM will struggle to disambiguate when all three are available. Consolidate or clearly separate by input/output contract.
No evidence of tool-chaining IDs in responses. If 'find_unused_indexes' returns index names, downstream tools like 'suggest_indexes' or other index modification tools must receive index_id or index_name from the prior response. Broken chains force wasteful lookup calls.
Tool source code not visible in provided snippets. Only Java backend service files and Dockerfiles are shown. The actual MCP tool registration, handler implementations, and response shaping are not included, preventing verification of schema completeness, error handling, and protocol compliance.