name: CloudBase Relational Database MCP

description: This is the required documentation for agents operating on the CloudBase Relational Database. It lists the only four supported tools for running SQL and managing security rules. Read the full content to understand why you must NOT use standard Application SDKs and how to safely execute INSERT, UPDATE, or DELETE operations without corrupting production data.

alwaysApply: false

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

- Inspecting or querying data in tables

- Modifying data or schema (INSERT/UPDATE/DELETE/DDL)

- Reading or changing table security rules

Do **NOT** use this skill for:

- Building Web or Node.js applications that talk to CloudBase Relational Database (use the Web/Node Relational Database skills)

- Auth flows or user identity (use the Auth skills)

1. **Recognize MCP context**

- If you can call tools like `executeReadOnlySQL`, `executeWriteSQL`, `readSecurityRule`, `writeSecurityRule`, 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**

- Reads → `executeReadOnlySQL`

- Writes/DDL → `executeWriteSQL`

- Inspect rules → `readSecurityRule`

- Change rules → `writeSecurityRule`

3. **Always be explicit about safety**

- Before destructive operations (DELETE, DROP, etc.), summarize what you are about to run and why.

- Prefer running read-only SELECTs first to verify assumptions.

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

- **Purpose:** Run `SELECT` queries (read-only).

- **Use for:**

- Listing rows, aggregations, joins.

- Inspecting data before changing it.

**Example call (conceptual):**

SELECT id, email FROM users WHERE active = true ORDER BY created_at DESC LIMIT 50;

Call this through the MCP tool instead of embedding SQL in code.

- **Purpose:** Run **write or DDL** statements:

- `INSERT`, `UPDATE`, `DELETE`

- `CREATE TABLE`, `ALTER TABLE`, `DROP TABLE`

- **Use for:**

- Data migrations

- Fixing or seeding data

- Schema changes

Before calling this tool, **confirm**:

- The target tables and conditions are correct.

- You have run a corresponding `SELECT` via `executeReadOnlySQL` when appropriate.

- **Purpose:** Read security rules for a given table.

- **Use for:**

- Understanding who can read/write a table.

- Auditing permissions on sensitive tables.

Security rule types typically include:

- `READONLY` – anyone can read, no one can write

- `PRIVATE` – only authenticated users can read/write

- `ADMINWRITE` – anyone can read, only admins can write

- `ADMINONLY` – only admins can read/write

- `CUSTOM` – custom security logic

- **Purpose:** Set or update security rules for a table.

- **Use for:**

- Hardening access to sensitive data

- Opening up read access while restricting writes

- Applying custom rules when needed

When using this tool:

- Clearly explain the **intent** (who should read/write what).

- Prefer standard rule types (`READONLY`, `PRIVATE`, etc.) before `CUSTOM`.

1. Use `executeReadOnlySQL` with a limited `SELECT`:

- Include a `LIMIT` clause.

- Filter by relevant conditions.

2. Review the result set and confirm it matches expectations.

This pattern prevents accidental full-table scans and gives you context before any write operations.

1. Use `executeReadOnlySQL` to inspect the current schema or data (if needed).

2. Plan the `CREATE TABLE` / `ALTER TABLE` statement.

3. Run it once via `executeWriteSQL`.

4. Optionally, validate by running `SELECT` again.

Always describe:

- What schema change you are making.

- Why it is safe in the current context.

1. Call `readSecurityRule` for the table to see current settings.

2. Decide on the target rule (e.g., from `READONLY` → `PRIVATE`).

3. Explain the change and why it matches the user’s requirements.

4. Call `writeSecurityRule` with the new rule.

5. Optionally, re-read the rule to confirm the update.

- **MCP tools** are for **agent operations** and **database management**:

- Run ad-hoc SQL.

- Inspect and change security rules.

- Do not depend on application auth state.

- **SDKs** are for **application code**:

- Frontend Web apps → Web Relational Database skill.

- Backend Node apps → Node Relational Database quickstart.

When working as an MCP agent, **always prefer these MCP tools** for CloudBase Relational Database, and avoid mixing them with SDK initialization in the same flow.

name: CloudBase Relational Database Web

description: Use when building frontend Web apps that talk to CloudBase Relational Database via @cloudbase/js-sdk – provides the canonical init pattern so you can then use Supabase-style queries from the browser.

alwaysApply: false

Use this skill whenever you need to access **CloudBase Relational Database from a browser app** (React, Vue, vanilla JS) using `@cloudbase/js-sdk`.

Use it when you need to:

- Initialize CloudBase Relational Database on the frontend

- Replace an existing Supabase client with CloudBase Relational Database

- Share a single `db` client across your Web app

**Do NOT use this skill for:**

- Backend/Node access to CloudBase Relational Database (use `relation-database-skill` → `node-sdk/quickstart.md`)

- MCP/agent database management (use `relation-database-skill` → `mcp-tools/mcp-guide.md`)

- Auth flows (use the Web/Node/Auth skills instead)

1. **Confirm environment**

- Ask the user for:

- `env` – CloudBase environment ID

2. **Follow the initialization pattern in this file exactly**

- Only change values like `env`, never the object shape.

3. **After initialization, use Supabase knowledge for queries**

- Treat `db` as a Supabase client – method names and patterns are identical.

4. **Avoid re-initializing CloudBase**

- Create a single shared `db` client and reuse it across components.

npm install @cloudbase/js-sdk

import cloudbase from "@cloudbase/js-sdk";

const app = cloudbase.init({

env: "your-env-id", // CloudBase environment ID

});

const auth = app.auth();

const db = app.rdb();

**Rules:**

- Do **not** invent new properties on the `cloudbase.init` options.

- Always call `app.rdb()` to get the database client; `app` is **not** the DB client.

import cloudbase from "@cloudbase/js-sdk";

const app = cloudbase.init({

env: "your-env-id",

});

export const db = app.rdb();

import { useEffect, useState } from "react";

import { db } from "../lib/db";

export function usePosts() {

const [posts, setPosts] = useState([]);

useEffect(() => {

async function fetchPosts() {

const { data } = await db.from("posts").select("*");

setPosts(data || []);

}

fetchPosts();

}, []);

return { posts };

}

const { data, error } = await db

.from("posts")

.select("*")

.order("created_at", { ascending: false });

if (error) {

console.error("Failed to load posts", error.message);

}

await db.from("posts").insert({ title: "Hello" });

await db.from("posts").update({ title: "Updated" }).eq("id", 1);

await db.from("posts").delete().eq("id", 1);

- After you have `db = app.rdb()`, use **Supabase documentation and patterns** for all queries.

- This skill only standardizes **Web initialization and client sharing**.

- Do not duplicate Supabase docs into this skill; rely on the model's built-in Supabase knowledge for query shapes and options.