Relational Database Mcp Cloudbase

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

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.