CloudBase AI Toolkit: giving coding agents a Tencent Cloud backend to operate
Backend for AI coding agents on CloudBase — database, auth, functions via Plugin, Skills & MCP.
At a glance
- What is it?
- The Toolkit bundles an MCP server, Agent Skills and IDE plugins so agents can provision and drive CloudBase databases, auth, functions and hosting. It is a thin control plane over a Tencent Cloud environment you still have to own.
- Who is it for?
- Adopt it if your backend already lives on CloudBase, or if you are willing to create a Tencent CloudBase environment and let an agent manage it from chat. Skip it if you need a provider-neutral backend layer or if you cannot review every schema, permission and deploy the agent proposes, since the README states the Toolkit supplies capability and path but not judgment.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap between generated code and a running backend
AI IDEs are good at producing application code. The README is explicit about where that stops: what usually blocks you is the backend, meaning schemas, permissions, functions, storage, environments and release. A generated React page or mini program screen is inert until something answers its requests. Someone has to create the environment, define collections, set access rules, wire authentication, deploy functions, and later read logs when a request fails. Those tasks are usually done by hand in a console, and that is the loop the Toolkit targets. The intended user is a developer working inside Cursor, Claude Code, Codex, CodeBuddy or Kimi who wants the agent to reach the backend from the same conversation where it wrote the frontend. It assumes you already have a CloudBase environment, which is Tencent Cloud's all-in-one backend covering database, storage, auth, cloud functions and Cloud Run. The Toolkit is not a backend. It is the integration layer between a backend you own and an agent that proposes changes to it.
Three pieces: Plugin, Agent Skills, MCP
The README splits the Toolkit into three parts with distinct jobs. The Plugin installs the MCP Server, the Agent Skills and Hooks together, which the project frames as less per-IDE wiring. Agent Skills are scenario documents covering Web, Mini Program, database, auth and functions, and their stated purpose is steering toward workable CloudBase practice rather than generic code. MCP is the operational surface: login, querying and changing data, managing functions and hosting, and reading logs, all from the conversation.
The repository ships the npm package @cloudbase/cloudbase-mcp along with the Skills and the AI plugins. The distinction matters when you choose an install path. The README says to prefer the Plugin for the full stack and Skills alone when you only need knowledge constraints, which is a useful admission that the Skills are just constraints on how the agent writes code, not a runtime. It also warns against doing both: for marketplace IDEs use this repository, and do not also run npx plugins add on the same tool. Running both paths is the most likely way to end up with two registrations of the same server.
How the MCP server reaches your environment
The data flow is agent to MCP server to CloudBase. The agent calls a tool, the MCP server authenticates and translates that call into a CloudBase operation, and the result comes back into the conversation. The README lists login, data queries and changes, function and hosting management, and log reads as the operating set.
Recent release notes show the surface expanding rather than settling. v2.33.x added custom container-image deployment for cloud functions with an async status query, plus a cloud upload channel through getUploadUrl and deployApp with a cosTimestamp. v2.33.x also introduced cloudbaserc.json as a field-level fallback for envId, region and site, accepting either a literal value or a {{env.KEY}} reference. v2.32.x added international-site login routing through TCB_SITE=intl and default environment-variable masking in queryFunctions and queryCloudRun. That masking default is the kind of decision worth noticing: it means the agent sees less by default, and you should confirm whether your version includes it before pasting function configuration into a chat. v2.31.x shows the project rewriting raw English deployment errors into suggested next tools, for example redirecting getDeployLog failures toward getProcessLog or getDeployRecords. Error rewriting is a real design choice, and it also means the agent's next step is being chosen by the server, not by you.
Installing it: the paths the README gives
The fastest documented route is a prompt rather than a command. The README gives this text to paste into your IDE:
Set up CloudBase for me: 1. Open https://docs.cloudbase.net/skill.md and complete the setup following its instructions. 2. Tell me when you're done, and suggest the most relevant next step.
The agent reads skill.md and performs the setup. Beyond that, the README offers a table of paths. For Claude Code and Codex with a native marketplace, add the repository as a marketplace and install the cloudbase plugin. For Open Plugin Spec tools, run npx plugins add TencentCloudBase/cloudbase-plugin, with a CNB fallback at https://cnb.cool/tencent/cloud/cloudbase/cloudbase-plugin.git. If you want one CLI across many tools, install the CloudBase CLI with npm i -g @cloudbase/cli and run tcb ai. For CodeBuddy, WorkBuddy, ZCode and Kimi, the README says to use the IDE's built-in CloudBase plugin or connector, and CodeBuddy can also install through the plugin marketplace. For other MCP-capable IDEs, configure MCP only. The README's MCP example is a JSON block with an mcpServers entry named cloudbase, using command npx and args ["@cloudbase/cloudbase-mcp@latest"]; the snippet is truncated in the supplied material, so treat the surrounding keys as something to confirm in the docs rather than copy from here. The dsh-plugin subdirectory is a separate package, @cloudbase/dsh-plugin, installed with dsh plugin add @cloudbase/dsh-plugin, described as an MCP bridge plus a database, storage and auth panel.
Where this design gets in the way
The Toolkit is bound to one backend. Every tool, every Skill and every example assumes CloudBase, so if your services run on AWS, Google Cloud or a self-hosted Postgres, the MCP server has nothing to operate. The repository topics list postgresql and supabase, but the README does not describe Supabase support, and nothing in the supplied material explains what those topics refer to. Do not read them as a compatibility promise.
The second constraint is judgment. The README states plainly that the Toolkit provides capability and path, not judgment, and that you should confirm sensitive actions the AI proposes. That is not modesty; it is the actual failure mode. An agent with database and function tools can change production data and deploy code. The masking default in queryFunctions and queryCloudRun reduces what leaks into the conversation, but it does not stop a destructive write. The error-rewriting behaviour in v2.31.x compounds this: when a deployment fails, the server suggests the next tool to call, and an agent that follows those suggestions can move further along a broken path before you notice.
The third issue is churn. Releases land in quick succession: v2.33.0 on 2026-09-04, then v2.33.1 and v2.33.2 on 2026-09-08. Each of those changed tool behaviour, added parameters, or altered defaults. Pinning @latest, as the README's MCP example does, means your agent's capabilities shift without you changing anything.
The alternative: a plain CLI or a provider-neutral layer
The obvious comparison is the CloudBase CLI on its own. The README lists it as a path for people who prefer one CLI across many tools: npm i -g @cloudbase/cli, then tcb ai. The difference is who holds the loop. With the CLI, you run commands and read output; the agent may write the command, but you execute it and see the result. With MCP, the agent calls the tool directly and the result returns into the conversation, which is faster and removes you from the middle. That is the trade. The CLI path keeps a human checkpoint on every backend mutation; the MCP path does not, unless you add one.
A second alternative is a provider-neutral backend layer, for instance a database and auth service that is not tied to one cloud. The difference in approach is that such a layer gives the agent the same interface regardless of where it runs, at the cost of the managed functions, hosting and mini program integrations that CloudBase provides natively. If your application is a WeChat mini program or a Tencent Cloud deployment, that neutrality buys you little. If it is a web app you might move, the CloudBase-specific tool surface becomes a migration cost later.
Maintenance, versions and the MIT licence
The repository is MIT licensed, which permits commercial use and modification, and the supplied material shows no additional terms. That is a statement about the licence text, not legal advice; if you redistribute the Toolkit or bundle it into a product, read the licence file yourself and check whether the CloudBase services it talks to carry separate commercial terms, since the Toolkit is only the client.
Upgrade cost is real because the surface changes often. The v2.32.x and v2.33.x notes describe new parameters, new fallback behaviour for cloudbaserc.json, new login routing, and changed defaults for environment-variable masking. If you pin a version, you avoid surprise changes but fall behind on fixes. If you follow @latest as the README example does, you inherit behaviour changes mid-project. The pragmatic middle is to pin in the MCP configuration and move deliberately, checking the changelog between versions. Note also the duplication warning: the README says not to run npx plugins add on the same tool where you already installed through the marketplace, so an upgrade that touches both paths can leave stale registrations behind.
Editorial conclusion
Adopt it if your backend already lives on CloudBase, or if you are willing to create a Tencent CloudBase environment and let an agent manage it from chat. Skip it if you need a provider-neutral backend layer or if you cannot review every schema, permission and deploy the agent proposes, since the README states the Toolkit supplies capability and path but not judgment. Before trusting it, verify three things: that your IDE path is the marketplace rather than a duplicate npx plugins add, that cloudbaserc.json resolves envId, region and site as the v2.33.x notes describe, and that queryFunctions and queryCloudRun mask environment variables by default in your version.
Community notes