/cloudbase-mcp

name: cloudbase-mcp
description: CloudBase MCP reference. Use when connecting local or remote MCP, calling tools from the shell with mcporter, reading tool schemas, choosing the domestic or international endpoint, setting site, region, cloud mode, or plugin flags, or contributing a fix to the open-source MCP server, skills, or CLI.
version: 2.36.1
license: MIT
alwaysApply: false

CloudBase MCP

Open source:

• GitHub: https://github.com/TencentCloudBase/CloudBase-AI-ToolKit
• Domestic mirror: https://cnb.cool/tencent/cloud/cloudbase/CloudBase-AI-ToolKit

The server source is `mcp/` in that repo. The package name is `@cloudbase/cloudbase-mcp`.

Sibling skills (local only)

Sibling CloudBase skills ship beside this skill. Use local relative paths such as `../cloudbase-cli/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.

• MCP setup, mcporter commands, and auth examples: `../cloudbase/references/mcp-setup.md`
• CLI fallback when MCP tools are not loaded: `../cloudbase-cli/SKILL.md`
• MCP vs CLI decision tree: `../cloudbase/references/tooling-fallback.md`

When to use

• The user is connecting MCP, or choosing local versus remote.
• The user or the agent calls CloudBase tools from the shell with mcporter, or needs a tool schema before calling.
• The user needs the site, region, cloud-mode, or plugin switches that already exist.
• A bug is in this repo's MCP server, skills, or CLI, and the fix should be a pull request.

Do not use this for

• Creating or changing cloud resources. Use the matching domain skill, or `../cloudbase-cli/SKILL.md` when MCP tools are not loaded.
• Cloud platform, permission, or account problems that are not code in this repo. Those go to an issue, not a pull request.

Connection

| Mode | Address | |------|---------| | Remote, domestic | `https://tcb-api.cloud.tencent.com/mcp/v1` | | Remote, international | `https://tcb-api.tencentcloud.com/mcp/v1` | | Local | `npx @cloudbase/cloudbase-mcp@latest` (Node.js 18.15+) |

The hostname decides the site. Remote URLs do not take a `site` query parameter.

• Interactive clients: put only the URL in the IDE config. The IDE opens a browser for login. This is the usual path.
• CI: add `env_id` and headers `X-TencentCloud-SecretId` / `X-TencentCloud-SecretKey`.
• Local stdio for the international site: `TCB_SITE=intl` and `TCB_REGION=ap-singapore`.

Pick the mode by these rules:

• **Remote** — the default. Interactive sign-in (browser OAuth) plus anything that runs entirely in the cloud.
• **Local** — when any one of these applies:
• the account signs in with a CloudBase API key (`CLOUDBASE_API_KEY`); remote has no API-key path, it accepts OAuth or Tencent Cloud SecretId/SecretKey only
• one session has to cover both the domestic and the international site; a remote URL is bound to a single site, while local switches with `TCB_SITE`
• the task needs a tool that remote does not register: `manageStorage` for uploading or downloading local files, `downloadTemplate`, `manageCloudRun`, or the declarative `deployBuild` / `deployPlan` / `deployApply` set

**Deploying functions or apps does not require local mode.** Remote deploys through the two-step upload: `queryFunctions(action="getFunctionUploadUrl")` or `queryApps(action="getUploadUrl")` → `PUT` the zip → `manageFunctions` with the `code` triple or `manageApps(action="deployApp", cosTimestamp=…)`. What remote lacks is the declarative `cloudbaserc` executor and a dry-run before applying.

The international site does not expose NoSQL tools in either mode.

Readiness check: missing tools are not the same as unconfigured

Run this before concluding MCP is unavailable, and before reaching for any workaround. Four different failures look alike from the outside and need different fixes.

1. **Wiring — is a tool registered in this session?** If no `cloudbase`-prefixed MCP tool appears in the current session's tool list, treat it as a wiring problem, not a credential problem. In hosts with a connector manager (WorkBuddy and similar), check the **installed** connector list first and reconnect from there. A bound connector is deliberately excluded from search and recommendation results, so "search returns nothing" does not mean "not installed". Search with the bare entity name (`cloudbase`), not a sentence — sentence-shaped queries match unrelated entries, and keyword filters do not help. Install only when it is genuinely absent. 2. **Credential — can the tool actually reach the environment?** When the tools are present, call `auth(action="status")` and require `auth_status: "READY"` plus the expected `current_env_id` before any cloud write. Anything else is a credential or binding problem, not a wiring problem. 3. **Session lifetime — when is a restart required?** Only after credentials change (first authorization, environment switch, key rotation); the running session caches the credential it started with. Enabling, disabling, or unbinding a connector does **not** require a new session — and unbinding does not revoke calls already flowing through an open session. To cut access immediately, close the session and rotate the credential. 4. **Triage instead of guessing.** No tool or `tool not found` → wiring. `auth` not READY → credential. READY but wrong `current_env_id` → binding. Network, signature, or permission errors → credential or gateway; reinstalling the connector will not help.

**Which call fixes which state.** The four cases above map to four different calls. Run the check; do not jump to a reinstall.

| State you observe | Call | Fixed looks like | |---|---|---| | No CloudBase MCP tool in this session's tool list | `list_installed_plugins(connectorName="cloudbase")`: `bound: true` → `reconnect_plugin(pluginName=<pluginName>)`; not listed → `search_plugins(type="conn