Loading ToolBench
CloudBase MCP Server — operate Tencent CloudBase (database, auth, functions, storage, hosting) from AI coding tools via the Model Context Protocol. Part of CloudBase AI Toolkit.
CloudBase MCP exhibits severe definition quality issues across all five tools. All tools use action-dispatch patterns with ambiguous enum parameters that lack proper schema validation. Tool names lack clear verb prefixes, parameter descriptions are minimal, and output schemas are completely undocumented. The server provides no guidance on what results to expect, how to chain tools, or how to handle errors. This is a classic case of exposing raw API routing logic as MCP tools rather than designing for agent consumption.
Manage CloudBase authentication with actions (set_env, status, start_auth, list_bound_envs)
Manage PostgreSQL database with DDL/DML execution (execute, applyMigration, repairMigration actions)
Query PostgreSQL database with action-aware toolview support (schema, metadata, objects, context actions)
Query CloudBase storage with action-aware toolview
Read NoSQL database structure with action-aware toolview (listCollections, describeCollection, structure, checkCollection actions)
All tools use action-dispatch pattern with ambiguous enum strings instead of discrete tools. 'action' parameter accepts free-form strings (sql, schema, metadata, objects, context) without enum constraints, forcing LLMs to guess valid values and enabling hallucinated actions.
Tool names lack action verbs. 'queryPgDatabase' uses 'query' (weak verb), 'managePgDatabase' conflates read/write ops, 'readNoSqlDatabaseStructure' buries the action in length, 'queryStorage' is generic, 'auth' is a noun. These names do not clearly signal intent to LLMs before reading descriptions.
No output schemas documented. Agents cannot plan downstream tool calls or know what fields to extract. For example, queryPgDatabase provides no schema, does it return rows as objects? Arrays? Metadata? This forces the LLM to handle unstructured output, wasting tokens and inviting parsing errors.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
Parameter descriptions are sparse and generic. 'action' is described only as 'Action type: sql, schema, metadata, objects, context' (36 chars), this lists possible values but does not explain when to use each action or what each produces. LLMs cannot reason about tool selection without WHEN/WHY context.
managePgDatabase conflates read and write operations in a single tool. 'applyMigration' and 'repairMigration' are destructive DDL/DML, but there's no confirmation step, dry-run mode, or clear indication of irreversibility. Agents cannot safely explore before executing.
Parameter 'collectionName' in readNoSqlDatabaseStructure is marked optional in context (some actions don't require it), but the schema does not declare optionality or document the conditional dependency. LLMs may pass it when not needed or omit it when required.
No error handling guidance provided. If an SQL query fails in queryPgDatabase or managePgDatabase, agents do not know whether to retry, ask the user to fix the query, or abort. Error responses should categorize issues as retryable, user-fixable, or fatal.
Tool names do not follow verb_noun convention. Production baselines show 90% of A+ tools start with action verbs (get, create, search, update, delete, list). CloudBase tools use weak or missing verbs: 'query' (ambiguous), 'manage' (too broad), 'read' (weak), 'query' (duplicate), 'auth' (noun).
Destructive operations (managePgDatabase) are not marked with risk or permission gates. No indication of what scope/permissions are required. A single 'execute' action can run any SQL, agents have no way to know they're about to drop a table.