relational-database-mcp-cloudbase（relational 数据库 MCP cloudbase）

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 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)

How to use this skill (for a coding agent)

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.

1. Pick the right tool for the job

- Reads → executeReadOnlySQL - Writes/DDL → executeWriteSQL - Inspect rules → readSecurityRule - Change rules → writeSecurityRule

1. 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.

Available MCP tools (CloudBase Relational Database)

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

1. executeReadOnlySQL

• 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.

2. executeWriteSQL

• 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

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

_openid VARCHAR(64) DEFAULT '' NOT NULL

💡 Note about _openid: When a user is logged in, the _openid field is automatically populated by the server with the current user's identity. You do NOT need to manually set this field in INSERT operations - the server will fill it automatically based on the authenticated user's session.

Before calling this tool, confirm:

• The target tables and conditions are correct.
• You have run a corresponding SELECT via executeReadOnlySQL when appropriate.

3. readSecurityRule

• 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

4. writeSecurityRule

• 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.

Scenario 1: Safely inspect data in a table

1. Use executeReadOnlySQL with a limited SELECT:

- Include a LIMIT clause. - Filter by relevant conditions.

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

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

Scenario 2: Apply a schema change

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.

Scenario 3: Tighten security rules on a sensitive table

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.

Key principle: MCP tools vs SDKs

• 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.