alibabacloud-suggest-cli

Alibaba Cloud CLI Command Suggester

Turn a natural-language Alibaba Cloud request into one or more aliyun CLI command strings, each ready to be passed as the command argument of the MCP CallCLI tool. After calling GenerateCLICommand, take the returned unifiedCli field verbatim; if unifiedCli is empty, fall back to cli. Do not manually rewrite either field. Commands must satisfy CallCLI's constraints, must pass check_cli.py validation before output, and are suggested only — do not run them unless the user explicitly asks.

Scope Check Before You Start

• CLI command suggestions (this skill): produce aliyun ... command strings (from GenerateCLICommand) for the MCP CallCLI tool. No execution, no SDK code.
• CLI syntax & troubleshooting reference → alibabacloud-cli-guidance: the knowledge base for plugin vs built-in routing, --biz- naming, auth, install, and error fixes. Read it when you need rules; this skill is the generation + validation loop on top of those rules.

Workflow

1. Split the request into atomic cloud operations. For each, verify the product, API/action name, version, and required parameters using MCP tools — do not guess.

2. Search APIs for operations whose action you are unsure about. Use AlibabaCloud___SearchApis with a natural-language description. Keep to one parallel batch.

3. Read API definitions to confirm exact parameter names, types, and which are required. Use AlibabaCloud___GetApiDefinition with product, action, and version. Do not skip this step for unfamiliar APIs.

4. Build jsonApiParameters from the API definition before generating the command. Prefer user-provided values. For missing values needed to make a useful suggestion, create reasonable mock values from the parameter structure returned by GetApiDefinition:

   • Use exact OpenMeta parameter names; never invent names from CLI flags or memory.
   • Include parameters marked required, plus small harmless shaping parameters for list/query APIs when useful (for example PageSize: 10, MaxItems: 10, or max-keys: 10) only if those parameters exist in the definition.
   • For region-like parameters, use the user's region when present; otherwise use cn-hangzhou.
   • For IDs, use realistic placeholders with the correct service prefix, such as i-test1234567890, vpc-test1234567890, vsw-test1234567890, sg-test1234567890, or eipalloc-test1234567890.
   • For names and descriptions, use short safe placeholders such as test-vpc, test-sg, or updated by static cli test.
   • For CIDR and network fields, use documentation-style private/test ranges such as 10.0.0.0/8, 10.0.1.0/24, or 203.0.113.0/24.
   • For enums and booleans, choose conservative valid-looking values from the parameter description or examples, such as tcp, accept, PayByTraffic, EcsInstance, or false.
   • For integer sizes/counts/bandwidths, use small values such as 1, 5, or 10.
   • For arrays/objects, preserve the schema shape: pass arrays as JSON arrays and objects as JSON objects in jsonApiParameters; do not flatten them into guessed CLI flags.
   • If a required parameter cannot be mocked safely from the definition, use a clear placeholder value like <instance-id> and mention that it must be replaced.