Static source inference · medium confidence · evidence: stateless requests
Current-spec patterns detected
Summary
dbhub provides 4 tools with basic descriptions and schemas, but significant gaps prevent a higher score. All tools have descriptions (good), and 3 of 4 have documented input schemas with types. However, descriptions are terse (15-60 chars), lack context about when to use each tool, and do not guide recovery on errors. Output schemas are not documented, LLMs cannot plan downstream calls. Tool naming is clear and verb-forward (execute_, search_, explain_, health_), but the server lacks error handling guidance, does not document constraints (e.g., SQL injection risks, rate limits), and provides no examples of response structure. The server is database-focused with good fundamentals but needs richer descriptions, documented output schemas, and error recovery guidance to reach production grade.
Tools (4)
execute_sqlwritesource verified63/100
Execute SQL queries on the database
explain_sqlread onlysource verified67/100
Show the execution plan for a SQL statement on the database without running it (always read-only)
health_checkread onlysource verified62/100
Report connection pool and buffer cache health metrics for the database (read-only)
search_objectsread onlysource verified63/100
Search and list database objects (tables, views, columns, etc.)
Tool descriptions are too terse (15 - 60 chars) and lack guidance on when to use each tool. 'Execute SQL queries on the database' does not explain prerequisites, error recovery, or relationship to explain_sql. LLMs cannot reliably select between similar tools without richer context.
Output schemas are not documented. Callers cannot see what fields are returned (e.g., does execute_sql return column names, row counts, affected rows?). Without documented output, LLMs cannot plan downstream calls or extract required IDs for chaining.
No error handling guidance. If execute_sql encounters a malformed query, invalid source_id, or connection timeout, the tool description does not tell the LLM what to do next (retry, ask user, check source_id, etc.). Raw error codes are useless to agents.
execute_sql
Recommendations
Expand execute_sql description to: 'Execute a SQL SELECT, INSERT, UPDATE, or DELETE statement on the database. Use explain_sql to see the execution plan without running the statement. Returns column names and row data for SELECT; row count for INSERT/UPDATE/DELETE. Cannot execute DDL (CREATE/DROP). Optional source_id selects which database connection to use (default: 'default'); call search_sources or check configuration to list available sources.'
Expand search_objects description to: 'Search for database objects (tables, views, columns, stored procedures) by name or pattern. Useful to discover schema before writing SQL queries. Requires a partial name or pattern (e.g., 'user' finds tables containing 'user'). Returns up to 50 results; use limit and offset for pagination. Does not search data inside tables, use execute_sql with SELECT for that.'
Expand explain_sql description to: 'Show the execution plan for a SQL query without running it. Use this to optimize slow queries or verify correctness before executing with execute_sql. Accepts only SELECT, INSERT, UPDATE, DELETE, not DDL. Returns database-specific plan format (may be text, tree, or structured). Always safe (read-only).'
Expand health_check description to: 'Report database connection pool status and buffer cache health metrics. Use to diagnose performance issues or verify the database is responding. Returns connection count, cache hit ratio, and any alerts. Read-only operation with no side effects.'
Add a 'query' parameter description for search_objects: 'Search query or pattern. Case-insensitive, supports % wildcards (e.g., 'user%' for names starting with 'user'). Partial matches are OK (e.g., 'account' finds 'AccountInfo', 'user_account').'
Parameter 'source_id' is optional and defaults to 'default', but the description does not explain what source_id is, how to discover valid values, or what 'default' refers to. LLMs cannot invoke the tool correctly without understanding source_id.
No constraints documented for 'sql' parameter (e.g., max length, allowed statements, SQL injection risks). LLMs may pass arbitrarily long or malicious SQL, risking resource exhaustion or unintended side effects.
execute_sql is marked as WRITE risk but has no confirmation/dry-run step documented. Agents may accidentally execute destructive queries (DROP TABLE, DELETE). Consider a destructive_action flag or require explicit confirmation for non-SELECT statements.
No pagination documented for search_objects. If the database has thousands of tables/columns, does the tool return all of them? If so, context will blow; if not, how does the LLM paginate? Missing limit/offset/cursor parameters and documentation.
search_objects
Add constraints for execute_sql 'sql' parameter: 'SQL statement (SELECT, INSERT, UPDATE, DELETE only; no DDL). Max 10,000 characters. Statements containing DROP, CREATE, ALTER, TRUNCATE are rejected. Use parameterized queries or prepared statements to prevent SQL injection.'
Document output schema for execute_sql: '{ "sql": string (statement executed), "columns": [string] (column names for SELECT), "rows": [[any]] (data rows), "rowCount": number (affected/selected rows) }'
Add error recovery guidance to all tool descriptions. E.g., execute_sql: 'If you get "source_id not found", call health_check first to verify the connection is available. If you get "syntax error", try explain_sql with a simpler query to identify the issue.'
Add source_id discovery hint: 'To list available database sources, see configuration or call health_check; if only one source is configured, source_id defaults to "default".'
Document pagination for search_objects: 'Accepts optional limit (1-100, default 50) and offset (0-based). Returns total count so LLM can fetch additional pages if needed.'
Add idempotentHint and readOnlyHint tool annotations (if supported by MCP server framework). Mark explain_sql, search_objects, health_check as read-only (readOnlyHint: true). Mark execute_sql with destructiveHint if used for DELETE/DROP.