Loading ToolBench
Multi-database query MCP tool supporting PostgreSQL, MySQL, MongoDB, Redis, and Oracle
PolyQuery MCP exhibits mixed quality across its 5 tools. All tools are explicitly registered with schemas and descriptions, which is foundational. However, descriptions are generic and translated (Chinese), parameter documentation lacks actionable constraints, and output schemas are not formally documented in the code. The server lacks error recovery guidance, parameter validation rules, and does not follow the naming convention of clear verb_noun patterns consistently. All tools are read-only (positive security posture), but lack information about which parameters are mutually exclusive or have dependencies. Schema quality is moderate, enum constraints are present for db_type but missing for connection_name and other critical parameters.
获取表/集合的结构信息
列出所有已配置的数据库及数据源
列出数据库中的所有表/集合
执行数据库查询。SQL数据库传SQL语句，MongoDB传JSON查询，Redis传命令字符串
测试数据库连接
Descriptions are generic and lack LLM-optimized guidance. 'Execute database query' and '列出数据库中的所有表/集合' (Chinese, untranslated for mixed-language audience) do not explain WHEN to use each tool or HOW results differ from similar tools. Baseline: A+ tools average 194 chars; these are 50-80 chars.
No output schema documentation in code or README. Tools return JSON with fields like 'success', 'data', 'row_count', 'execution_time_ms', but these are not formally declared. LLMs cannot predict the response structure without trial, risking extraction errors and context loss.
Parameter 'connection_name' is described as 'optional, default uses default' in all tools, but no enum or constraint is provided. LLMs cannot discover valid connection names without first calling list_databases. This forces a discovery call before most operations, wasting latency and context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Error handling returns only success/error boolean and error message string. No recovery guidance. Example: if query fails due to syntax error, the response is {success: false, error: '...'} with no hint to try describe_table or test_connection first. Baseline: A+ tools include 'Try X next' or categorize errors as retryable/user-fixable/fatal.
'query_database' accepts 'query' as a single string but does not validate syntax, database type compatibility, or explain the expected format per database. Description says 'SQL/Redis/MongoDB JSON' but does not clarify that MongoDB expects a stringified JSON object while Redis expects a command string. LLMs will conflate formats.
'limit' parameter has a default (Config.MAX_ROWS) but no minimum or maximum bounds declared. If MAX_ROWS is high (e.g., 10000), LLMs may pass enormous limits causing context overflow or performance issues. Baseline requires explicit min/max for numeric params.
No tool composition guidance. If an LLM needs to discover table names before querying, the description of 'query_database' does not hint 'Call list_tables first.' This forces agents to reason about tool ordering, wasting cycles.
Configuration is via .env file (dotenv). Credentials and connection strings are server-side injected, which is correct, but if an agent somehow passes a connection_name that doesn't exist, the error message does not list available connections. Error recovery is blocked.