Loading ToolBench
MCP server integration for Aliyun ComputeNest with support for OSS file downloads, APIG registration, Higress gateway management, and MCP tool auto-registration
This server exhibits pervasive deficiencies in definition quality. Of 15 tools, 14 have minimal to moderate descriptions (mostly 30-80 chars, below the 194-char baseline for A+ tools). Input schemas are present but lack depth: most parameter descriptions are one-liners, and none declare enums, ranges, or validation rules. Parameter names are sometimes unclear (e.g., 'config' as a generic object). Output schemas are completely undocumented, we see no guidance on what fields agents should expect from any tool's return value. Error handling is absent: no recovery guidance, no error categorization, no actionable messages. The tools span multiple domains (OSS, APIG, Higress, gateway state) without clear composition or chaining support. Critical security issues: 'api_key' and 'password' appear as bare parameters, violating secret-injection patterns. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (WRITE, DESTRUCTIVE). Tool 13 (clear_all_state) is a destructive operation with no confirmation mechanism.
Add tool record to MCP gateway state with tool name and MCP server ID
Check Higress connectivity and create config directory if needed
Clear all stored MCP gateway state
Create MCP server in APIG with backend configuration pointing to FC3 service
Batch create APIG services for FC3 functions and return mapping of function names to service IDs
Download MCP server packages from Aliyun OSS based on configuration file specifying bucket name and package paths
Retrieve all tools from MCP gateway state
Secrets exposed as tool parameters: 'api_key' (update_higress_console_secret, init_system) and 'password' (login) appear as raw string parameters. Agent logs will capture these credentials, violating secret-injection patterns and creating compliance/audit risk.
Output schemas completely undocumented. No tool provides guidance on return value structure, field types, or which fields downstream tools need. Agents cannot plan chained calls or extract required IDs (e.g., what does create_services return? Is it {service_name: service_id} or a list of service IDs?).
Destructive operations lack confirmation mechanism. Tool 13 (clear_all_state) has risk=DESTRUCTIVE but no dry-run, confirmation, or explicit user approval pattern. An agent could erase all state in one call.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Retrieve stored gateway information (gateway ID, domain ID, service ID, service name)
Retrieve the HttpApiId for MCP type from Aliyun APIG gateway
Check whether gateway state has been initialized
Initialize Higress system with admin user and password before first login
Authenticate to Higress service with username and password
Remove tool record from MCP gateway state
Update MCP gateway state with gateway ID, domain ID, service ID, and service name
Update adminPassword in secrets/higress-console.yaml with base64-encoded API key
Tool annotations missing. 12 tools have explicit risk levels (READ_ONLY, WRITE, DESTRUCTIVE) but these are not communicated to agents via readOnlyHint, destructiveHint, or idempotentHint in the MCP schema. Agents cannot reason about which calls are safe to retry.
Parameter descriptions lack validation constraints. Example: 'gateway_id' is described only as 'Aliyun APIG gateway ID' with no format, length, or validation pattern. Parameters like 'fc3_names' (an array) have no guidance on item type or constraints.
Generic parameter names without type suffixes. Example: 'config' in create_mcp_server is described as 'Configuration object with gatewayExposure, protocol, type, etc.' but provides no schema. Passing such an opaque object forces agents to hallucinate field names.
No error handling guidance. No tool documents what errors it may return, whether they are retryable, or how agents should recover. Example: download_oss_packages could fail if bucket_name is invalid, ossutil is not installed, or network is down, but agents get no recovery path.
Unclear tool composition and chaining. The 15 tools span multiple services (OSS, APIG, Higress, gateway state) without clear dependency documentation. Example: does create_mcp_server depend on create_services? What IDs must be passed between them? The agent must infer this.
Ambiguous verb for state management tools. 'update_gateway_info', 'add_tool', 'remove_tool', and 'clear_all_state' all modify gateway state but do not clarify whether they're atomic, idempotent, or reversible.