Loading ToolBench
MCP servers for Alibaba Cloud PolarDB database management with OpenAPI, MySQL, and PostgreSQL support including slow log analysis and performance monitoring
This MCP server suite spans three separate implementations (MySQL, PostgreSQL, OpenAPI) with 18 total tools. While tool naming generally follows verb_object conventions (execute_sql, import_knowledge_base, query_knowledge_base, polardb_restart_db_node), the definitions suffer from significant gaps in parameter documentation, output schemas, and error handling guidance. Many tools lack sufficient description length to guide LLM selection (baseline: 194 chars avg, p10=34). Critical issue: tool definitions appear inferred rather than explicitly registered with full schema visibility, only sample code is provided for the MySQL server, making verification of complete schema definitions impossible. The OpenAPI-based tools (polardb_smart_query, polardb_restart_db_node, etc.) show better naming but lack visible schema definitions in source. Parameter descriptions are present but often generic (e.g., 'The ID of the PolarDB database node' for dbnode_id). No documented output schemas, pagination strategies, or error recovery guidance visible in provided source. The suite does not follow composition patterns for multi-step operations (e.g., restart + verify is split across tools without explicit chaining guidance).
Execute an SQL query on the PolarDB MySQL server
Execute an SQL query on the PolarDB PostgreSQL server
Import documents into a PolarDB knowledge base with vector embeddings
Create a new PolarDB cluster
List available resources for creating PolarDB clusters
Get detailed information about a specific PolarDB cluster
Get the IP whitelist for a specific PolarDB cluster
Duplicate tool names: Two 'execute_sql' tools (MySQL and PostgreSQL) exist without distinguishing names. LLMs cannot reliably route calls to the correct database, risking wrong-database execution.
Missing output schemas: 15 of 18 tools lack documented output structure. LLMs cannot plan downstream calls or extract required IDs (e.g., cluster_id returned by polardb_create_cluster? Format? What fields?). Baseline: 100% of A+ tools document return types.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 31 | - | v1 |
Get performance metrics for a specific PolarDB cluster within a time range
List all PolarDB clusters in a specific region
Get configuration parameters for a specific PolarDB database node
Get performance metrics for a specific PolarDB database node within a time range
List all available regions for Alibaba Cloud PolarDB
Get slow log records for a specific PolarDB cluster within a time range
Extract node IDs from a specific PolarDB cluster
Modify configuration parameters for PolarDB database nodes
Restart a PolarDB database node
Smart query dispatcher that understands natural language intent - supports Chinese and English queries for PolarDB operations like node restart, cluster performance, cluster info, whitelist management, and node extraction
Query the PolarDB knowledge base using semantic search with vector embeddings
Weak descriptions for discovery tools. polardb_describe_regions (42 chars), polardb_restart_db_node (56 chars) fall below effective minimum (baseline p10=34 but median=194). Too short to guide LLM selection vs. similar tools. No WHEN to use guidance.
No enum constraints on choice parameters. polardb_describe_available_resources accepts db_type (string, no enum), leading LLM to hallucinate 'Oracle' or 'Redis'. polardb_describe_db_cluster_performance accepts key as comma-separated string with no valid options listed.
Parameters passed as strings requiring manual parsing. polardb_modify_db_node_parameters expects JSON as string ('parameters' param), forcing LLM to construct JSON manually. dbnode_ids is comma-separated string, not array. This invites syntax errors and wasted retry cycles.
No error recovery guidance. Destructive tools (polardb_restart_db_node, polardb_create_cluster) lack dry-run, confirmation, or explicit error categories (retryable vs. fatal). If restart fails, LLM has no recovery path.
Inconsistent parameter naming across tools. 'dbcluster_id' vs. 'db_cluster_id' (polardb_describe_db_cluster_access_whitelist uses underscore inconsistently). LLMs struggle with similar-but-not-identical parameter names, risking type mismatches.
polardb_smart_query is vague. Named 'smart_query' with description mentioning 'dispatcher' but no output structure documented. Unclear what intent detection returns (structured? Natural language summary?). Marked WRITE but underlying sub-operations unclear.
No pagination guidance for large result sets. polardb_describe_slow_log_records has page_size max of 2,147,483,647 (unrealistic). No cursor-based pagination, no guidance on result limits, no context-window optimization.
Tool definitions appear inferred, not explicitly visible. Source code provided is partial (sample from server.py, not complete tool registration). Cannot verify full schema definitions, registration methods, or initialization logic. Caps verification confidence.