/relational-database-mcp-cloudbase

name: relational-database-mcp-cloudbase
description: "[Deprecated] This is the required documentation for agents operating on the CloudBase Relational Database through MCP. It defines the canonical SQL management flow with `queryMysqlDatabase`, `manageMysqlDatabase`, `queryPermissions`, and `managePermissions`, including MySQL provisioning, destroy flow, async status checks, safe query execution, schema initialization, and permission updates. New environments should use PostgreSQL — see postgresql-development skill instead."
version: 2.26.0
alwaysApply: false
metadata:
  priority: "5"
  deprecated: "true"

Sibling skills (local only)

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

Activation Contract

Use this first when

• The agent must inspect SQL data, execute SQL statements, provision or destroy MySQL, initialize table structure, or manage table security rules through MCP tools.

Read before writing code if

• The task includes `queryMysqlDatabase`, `manageMysqlDatabase`, `queryPermissions`, or `managePermissions`.

Then also read

• Web application integration -> `../relational-database-web-cloudbase/SKILL.md`
• Raw HTTP database access -> `../http-api-cloudbase/SKILL.md`

Do NOT use for

• Frontend or backend application code that should use SDKs instead of MCP operations.

Common mistakes / gotchas

• Initializing SDKs in an MCP management flow.
• Running write SQL or DDL before checking whether MySQL is provisioned and ready.
• Treating document database tasks as MySQL management tasks.
• Skipping `_openid` and permissions review after creating new SQL tables.
• Destroying MySQL without explicit confirmation or without checking whether the environment still needs the instance.
• Using `getConnectionInfo` (or inferred host/password) to build a default TCP client for new apps. Prefer SDK / `runQuery` / `runStatement`; TCP credentials are an explicit migration exception only.

When to use this skill

Use this skill when an **agent** needs to operate on **CloudBase Relational Database via MCP tools**, for example:

• Inspecting or querying SQL data
• Provisioning MySQL for an environment
• Destroying MySQL for an environment
• Polling MySQL provisioning status
• Modifying data or schema (INSERT/UPDATE/DELETE/DDL)
• Initializing tables and indexes after MySQL is ready
• Reading or changing table permissions

Do **NOT** use this skill for:

• Building Web or Node.js applications that talk to CloudBase Relational Database directly through SDKs
• Auth flows or user identity management

How to use this skill (for a coding agent)

1. **Recognize MCP context**

• If you can call tools like `queryMysqlDatabase`, `manageMysqlDatabase`, `queryPermissions`, `managePermissions`, you are in MCP context.
• In this context, **never initialize SDKs for CloudBase Relational Database**; use MCP tools instead.

2. **Pick the right tool for the job**

• Read-only SQL and provisioning status checks -> `queryMysqlDatabase`
• MySQL provisioning, MySQL destruction, write SQL, DDL, schema initialization -> `manageMysqlDatabase`
• Inspect permissions -> `queryPermissions(action="getResourcePermission")`
• Change permissions -> `managePermissions(action="updateResourcePermission")`

3. **Always be explicit about safety**

• Before destructive operations (DELETE, DROP, etc.), summarize what you are about to run and why.
• Prefer `queryMysqlDatabase(action="getInstanceInfo")` or a read-only SQL check before writes.
• Provisioning or destroying MySQL requires explicit confirmation because both actions have environment-level impact.

---

Available MCP tools (CloudBase Relational Database)

These tools are the supported way to interact with CloudBase Relational Database via MCP:

1. `queryMysqlDatabase`

• **Purpose:** Query SQL data and provisioning state.
• **Use for:**
• Running `SELECT` and other read-only SQL queries with `action="runQuery"`
• Checking whether MySQL already exists with `action="getInstanceInfo"` (lifecycle only — no connection credentials)
• Inspecting asynchronous provisioning progress with `action="describeCreateResult"` or `action="describeTaskStatus"`
• **Exception only:** `action="getConnectionInfo"` returns the raw connection/cluster payload (may include credentials) for migrating existing TCP/ORM clients. Do **not** use this for new business CRUD — prefer Web/Node SDK or `runQuery` / `runStatement`.

**Example flow:**

{
  "action": "runQuery",
  "sql": "SELECT id, email FROM users ORDER BY created_at DESC LIMIT 50"
}

**Do NOT** call `getConnectionInfo` and then wire `pymysql` / `mysql2` / `DATABASE_URL` into a cloud function for greenfield apps. Platform-delegated SQL and SDK access are the default.

2. `manageMysqlDatabase`

• **Purpose:** Manage SQL lifecycle and execute mutating SQL.
• **Use for:**
• Provisioning MySQL with `action="provisionMySQL"`
• Destroying MySQL with `action="destroyMySQL"`
• Executing `INSERT`, `UPDATE`, `DELETE`, `CREATE TABLE`, `ALTER TABLE`, `DROP TABLE` with `action="runStatement"`
• Initializing tables and indexes with `action="initializeSchema"`

**Important:** When creating a new table, you **must** include the `_openid` column for per-user access control:

_openid VARCHAR(64) DEFAULT '' NOT NULL

Note: when a user is logged in, `_openid` is automatically populated by the server from the authenticated session. Do not manually fill it in normal inserts.

Before calling this tool, **confirm**:

• The current environment has a ready MySQL instance, or you have just provisioned one.
• The target tables and conditions are correct.
• You have run a corre