Relational Database 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.

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.

---

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.

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.

---

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.