Operate Tencent Cloud resources that CloudBase depends on but that no dedicated MCP tool covers (monitoring & alarms, CLB, CAM roles, cross-product infra). Two goals: find the right API without guessing, and reuse proven workflows instead of re-exploring.
Sibling skills (local only)
Sibling CloudBase skills ship beside this skill. Use local relative paths such as ../cloudbase-platform/SKILL.md.
If a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do not HTTP-fetch remote skill or protocol markdown into the agent context.
When to use
- The user asks to manage/operate Tencent Cloud resources beyond CloudBase's dedicated MCP tools (e.g. configure alarm policies, inspect CLB, attach CAM policies).
- The user wants to control these resources from code and asks which API/SDK to use.
- A callCloudApi call failed and you need to classify the error (wrong Action / wrong params / missing CAM permission) and recover.
Workflow
1. Discover the API — resolve names from a documented source
- Read the API index first: https://docs.cloudbase.net/ai/cloudbase-ai-toolkit/api-reference.md — auto-synced daily, action-level coverage (TCB 105 + dependency products: MySQL / SCF / COS). Check rate limits there too. The index check is a quick grep — run it in parallel with step 2/3 fetches, do not serialize.
- If the index does not cover the target product, go to the product's official API docs (e.g. monitor: https://cloud.tencent.com/document/product/649/30343) and confirm the exact Action name, Version, and parameters.
- For machine-readable parameter schema, fetch the official SDK models source directly — see
./references/calling-methods.md§2 item 4.
Done when: the Action name, Version, and full parameter shape each trace to the index, official product docs, or SDK models source — nothing from memory. A call that still returns action ... is invalid or not found means a name was not resolved this way; classify and recover via the error table in ./references/calling-methods.md §1.
API first: the public API overview is the contract boundary. If a capability cannot be found in the index, it is not within the public contract — do not reverse-engineer an undocumented Action name to call from some SDK's wrapper method (such Actions are not protected by public documentation, and users of other languages have no way to follow suit). In this case, use an equivalent path that has a public API, or clearly tell the user about the gap. The recipes in this skill only cover scenarios covered by the public API.
2. Choose the calling path
| Scenario | Path | Reference |
|---|---|---|
| Interactive ops inside this session | MCP callCloudApi |
./references/calling-methods.md §1 |
Picking the service identifier / deciding whether version is needed |
MCP callCloudApi |
./references/service-versions.md |
| User's code / scripts | Official SDKs (TC3-HMAC-SHA256) or @cloudbase/manager-node |
./references/calling-methods.md §2 |
| Quick one-off verification | API Explorer (https://console.cloud.tencent.com/api/explorer) | — |
Priority rule: if @cloudbase/manager-node has a matching method, use it; drop to raw cloud API only when it does not.
3. Check credentials before the first call
- Read the current credential scope from
authtools:credential_scope: account= account-level, reaches control-plane APIs subject to that identity's CAM policies;env= API Key, scoped to one environment's data plane plus the fixed TCB policies. - Permission comes from a different place per credential identity: the account-level identity's own policies, the API Key model (no channel to attach arbitrary CAM policies), or the TCB service role that CLI / MCP assume. Which cross-product capabilities that role family already covers is not fixed — read the attached policies (
ListAttachedRolePolicies+GetPolicy) instead of assuming, and treatUnauthorizedOperationas "this identity lacks this action", never as a broken setup. - On
UnauthorizedOperation/AuthFailure, hand the user a one-click CAM grant link (role name + policy name +principal) instead of telling them to go find the policy in the console, then retry the original call. Role targets, theprincipalvalues, and which preset policy covers what:./references/calling-methods.md§3.
Done when: the credential identity is known, and every permission error has been converted into a clickable authorization link carrying a concrete policy name before any retry.
4. Follow a proven recipe when one exists
Recipes encode the exact call sequence, required parameters, and empirically discovered pitfalls so the flow works on the first pass. One scenario per file — start from the index ./references/recipes/README.md, whose status column records how far each recipe has been verified:
- PostgreSQL storage-usage alarm:
./references/recipes/pg-storage-alarm.md - ICP filing readiness and wait-time checks:
./references/recipes/icp-filing-readiness.md
Done when: every parameter value in the call sequence traces to a recipe value marked as verified (measured) or to official docs.
Constraints
- Region is a top-level
regionargument (X-TC-Region), never a body param. Some APIs additionally take a short region code insideDimensions(e.g.shvsap-shanghai) — these are different fields. - Route SDK-language details to official SDK docs or sdkHints; keep this skill SDK-language-agnostic.