bytebase-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@bytebase-mcp what databases are available in production?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
bytebase-mcp
MCP server for Bytebase — SQL Editor, schema catalog, query history, and the full change-plan workflow over the Connect-RPC API. Authentication is the standard MCP OAuth 2.1 flow (PKCE public client, dynamic registration) — the same flow MCP clients like Claude Code and opencode run against remote MCP servers.
No browser automation. No static tokens. No background daemon. No bundled certificates — everything resolves from environment variables.
Authentication model
Implements the MCP SDK's OAuthClientProvider + auth():
RFC 9728 protected-resource discovery → authorization-server metadata → RFC 7591 dynamic client registration → PKCE (S256) authorization-code flow
One token file per instance (
~/.config/bytebase-mcp/<host>.json, mode 600) is the only credential storeRefresh under an atomic
mkdirlock — the one filesystem operation that is atomic on both Windows and POSIX — and the file is re-read after taking the lock, so a process that loses the race picks up the winner's tokens. This matters: Bytebase's refresh token is single-use with no reuse grace, and MCP clients spawn one process per session, all sharing one grantSingle-flight within a process: concurrent 401s share one refresh
Access tokens re-mint on demand; the 1-hour expiry never surfaces
401 self-heal: the client passes the stale token to the refresh path, so cross-process rotation is detected, never double-burned
Related MCP server: rocks-db
Setup
npm install
cp .env.example .env # set BYTEBASE_URL
npm run build
npm run auth # standard MCP OAuth 2.1 login (prints the approval URL)
npm run auth:status # grant health, no secrets
npm run probe # preflight: TLS, grant, identity, projectsThe login prints a URL; open it in any browser, approve, and the loopback listener captures the redirect. Re-login is needed roughly every 30 days.
MCP configuration
{
"mcpServers": {
"bytebase": {
"command": "node",
"args": ["C:/path/to/bytebase-mcp/dist/index.js"],
"env": { "BYTEBASE_URL": "https://bytebase.example.com" }
}
}
}Tools (14)
Tool | Description |
| Identity, server version, token life, visible projects — run first when debugging auth |
| Projects the identity can see |
| Databases with instance/engine/environment (the |
| Find tables by name/column (~1000-table prod DBs) |
| Columns, indexes, foreign keys |
| SQL through the SQL Editor — read-only by default (SELECT/WITH/SHOW/DESCRIBE/EXPLAIN), routed to the read-only replica when one exists; write SQL requires |
| Recent queries recorded by Bytebase |
| Schema/data change issues with approval status |
| Draft a SQL change plan (Sheet + Plan) — no SQL runs until a human approves |
| Plan details incl. decoded SQL |
| Edit title/description/SQL of a draft or in-review plan |
| Labels a project requires on review issues |
| Open the review Issue — starts the approval workflow |
| Cancel a draft or its open review issue (refuses after rollout starts) |
Write safety: bytebase_query blocks writes by default; the plan workflow is the write route — it creates a reviewable proposal that only executes after human approval in the Bytebase UI.
Environment variables
All configuration is environment-driven — nothing site-specific is bundled.
Variable | Default | Purpose |
| — | Instance base URL (required) |
|
| Token file location |
|
| Loopback OAuth redirect port |
| unset | Allow write SQL in |
| 200 / 5000 | Row caps |
| — | Outbound proxy |
| — | Extra CA for servers with an incomplete cert chain |
Development
npm run typecheck && npm run build && npm test
npm run probe # live preflight against .env
node test/mcp-e2e.mjs # full stdio protocol test (needs auth)Releasing
CI runs on every push and PR (typecheck → build → tests). Publishing is GitHub-Release-driven and uses npm Trusted Publishers (OIDC — no token secret in CI):
# 1. Bump "version" in package.json, commit and push to main
# 2. Create a GitHub Release (web UI, or):
gh release create v0.2.1 --generate-notes --repo ahmedbally/bytebase-mcpOn publish, the workflow verifies the release tag matches package.json, runs the full verification, publishes to npm with a provenance attestation, and appends the published version to the release notes.
One-time setup (repo owner): on npmjs.com → bytebase-mcp → Settings → Trusted Publisher, add ahmedbally/bytebase-mcp with workflow publish.yml (no environment). Until that's configured, release publishing will fail with 403.
License
MIT
Available Tools
14 toolsbytebase_close_planBytebase: close a plan or its review issueA
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.
Inputs: plan (required).
bytebase_create_planBytebase: create a SQL change planA
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.
Inputs: title (required), database (required), statement (required), description, +1 more.
bytebase_describe_tableBytebase: describe tableA
Full definition of one table: columns with types and nullability, indexes, and foreign keys.
Inputs: table (required), database (required).
bytebase_get_planBytebase: get a planA
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.
Inputs: plan (required).
bytebase_list_databasesBytebase: list databasesA
List databases with their instance, engine and environment. Use this to discover the reference string to pass to bytebase_query (format: //).
Inputs: search, project, refresh, environment.
bytebase_list_issue_labelsBytebase: list issue labelsA
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.
Inputs: project (required).
bytebase_list_issuesBytebase: list change issuesB
List schema/data change issues in a project, with review and approval status.
Inputs: project (required), limit, status.
bytebase_list_projectsBytebase: list projectsA
List every Bytebase project the configured identity can see.
Inputs: refresh.
bytebase_queryBytebase: run SQL queryA
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.
Inputs: database (required), statement (required), limit, dataSource.
bytebase_query_historyBytebase: recent query historyA
Recent SQL Editor queries recorded by Bytebase. Useful for recovering a query you ran earlier or seeing how a table is normally joined.
Inputs: limit, database.
bytebase_search_tablesBytebase: search tablesA
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.
Inputs: database (required), limit, pattern.
bytebase_submit_plan_for_reviewBytebase: submit a plan for reviewA
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.
Inputs: plan (required), labels.
bytebase_update_planBytebase: update a planA
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.
Inputs: plan (required), title, statement, description.
bytebase_whoamiBytebase: identity & connectivity checkA
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.
Inputs: no named parameters.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 14 tools
Most tools target distinct resources/actions (projects, databases, tables, plans, issues), but bytebase_list_issues and bytebase_list_issue_labels could be confused at a glance, and bytebase_get_plan/update_plan/close_plan are clearly grouped. The plan lifecycle tools are well-differentiated by descriptions.
All tools follow a consistent bytebase_<verb>_<noun> pattern (list_projects, describe_table, submit_plan_for_review). Verbs are clear and predictable, with no mixed casing or stylistic deviations.
14 tools is well within the ideal range for a database management server covering discovery, querying, and change workflows. Each tool maps to a meaningful operation in Bytebase's domain.
The surface covers database discovery, schema inspection, read-only querying, and the plan/review lifecycle well. Minor gaps: no direct tool for listing/creating databases or managing issues beyond listing, but the core workflows are complete and the write path is intentionally gated.
Maintenance
Related MCP Connectors
Connect to PlanetScale databases, branches, schema, query insights, and execute SQL
Manage Fly.io apps, Machines, volumes, secrets, Managed Postgres, and Sprites with OAuth.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Related MCP Servers
- -licenseNot gradedqualityNot gradedmaintenanceEnables IDE access to Supabase databases with SQL query execution, schema management, Auth admin operations, and built-in safety controls to prevent accidental destructive actions.-
- AlicenseNot gradedqualityDmaintenanceEnables executing SQL queries (SELECT, INSERT, UPDATE, DELETE) and database introspection (list tables, describe table) on MySQL and PostgreSQL databases with OAuth authentication.ISC

@matihlabs/mcpofficial
AlicenseNot gradedqualityCmaintenanceConnects AI clients to the Matih data platform, enabling SQL queries, table profiling, analytics, chart creation, and file uploads through MCP tools with OAuth/PKCE authentication.83 npmApache 2.0- AlicenseNot gradedqualityBmaintenanceEnables AI assistants to query Postgres as the signed-in person through OAuth 2.1/OIDC, with database-enforced read-only queries, PII masking, human-approved writes, and a tamper-evident audit log.23Apache 2.0