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)
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.
Pick the right tool for the job
Reads →
executeReadOnlySQL
Writes/DDL →
executeWriteSQL
Inspect rules →
readSecurityRule
Change rules →
writeSecurityRule
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
Use
executeReadOnlySQL
with a limited
SELECT
:
Include a
LIMIT
clause.
Filter by relevant conditions.
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
Use
executeReadOnlySQL
to inspect the current schema or data (if needed).
Plan the
CREATE TABLE
/
ALTER TABLE
statement.
Run it once via
executeWriteSQL
.
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
Call
readSecurityRule
for the table to see current settings.
Decide on the target rule (e.g., from
READONLY
→
PRIVATE
).
Explain the change and why it matches the user’s requirements.
Call
writeSecurityRule
with the new rule.
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.