Verify the configured Bytebase token: returns the server version, the identity it maps to, and how long the token remains valid. Run this first when anything returns 401/403.

List every Bytebase project the configured identity can see.

List databases with their instance, engine and environment. Use this to discover the reference string to pass to bytebase_query (format: //).

Find tables in a database by name or column name. Prefer this over dumping a schema — a production database here can hold ~1000 tables. Returns names and row counts only; use bytebase_describe_table for columns.

Full definition of one table: columns with types and nullability, indexes, and foreign keys.

Execute SQL through the Bytebase SQL Editor and return rows as JSON. Read-only: only SELECT/WITH/SHOW/DESCRIBE/EXPLAIN are accepted. Queries run under the configured Bytebase identity and are subject to its access policies, data masking and audit log.

Recent SQL Editor queries recorded by Bytebase. Useful for recovering a query you ran earlier or seeing how a table is normally joined.

List schema/data change issues in a project, with review and approval status.

Draft a titled SQL change plan against one database: creates a Sheet (the SQL text) and a Plan (the proposal) in Bytebase. This does NOT open an Issue and does NOT run the SQL — a plan only becomes executable after a human opens it in the Bytebase UI, submits it for review, and it is approved, at which point Bytebase creates the rollout automatically. Available even when BYTEBASE_ALLOW_WRITE is unset, since nothing runs until a human approves it — this is the safe route for write SQL that bytebase_query blocks in read-only mode.

Fetch a plan's title, description, target database, status, and full SQL statement (decoded from its Sheet). Use this before bytebase_update_plan to see the current content.

Edit a plan's title, description, and/or SQL statement — works both before and after it has been submitted for review (title edits go to the review Issue instead of the Plan once one exists, matching Bytebase's own UI). Changing the statement creates a new Sheet (sheets are immutable) and repoints the plan at it — refused once the plan has a rollout, since tasks may already reference the old sheet. Only supports single-spec plans — i.e. plans created by bytebase_create_plan.

List the issue labels a project has configured. Call this before bytebase_submit_plan_for_review when the project defines any labels, so the caller can offer them as choices rather than guessing label names — "required: true" means Bytebase will reject the issue if none are attached.

Open a review Issue for a Plan created with bytebase_create_plan. This is the step that actually starts the approval workflow — once approved and its checks pass, Bytebase creates the rollout and runs the SQL. Do not call this unless the user has confirmed the plan is ready to go out for review. If the project defines issue labels (check with bytebase_list_issue_labels first), ask the user which ones to attach instead of guessing.

Cancel a change before it runs. If the plan was never submitted for review, this deletes the draft plan. If it was submitted (an open review Issue exists), this cancels that issue instead — mirroring the "Close" action in the Bytebase UI. Refuses if the plan already has an active rollout: at that point tasks may be running or done, and canceling them needs the Bytebase UI's task-level actions.