# Database MCP Server

> The Bytebase MCP server: governed reads and changes for AI agents, built into Bytebase. The agent connects to Bytebase, not the database. A workspace access policy (Disabled, Read-only, Read-write; Read-only for new workspaces) caps every MCP session, each session runs under the signed-in user's permissions, sensitive columns are masked on the read path, writes go through SQL review and approval, and every query and change is audit-logged with an MCP tag. Self-hosted or Bytebase Cloud, open-source, PostgreSQL, MySQL, SQL Server, Oracle, and 20+ engines.

Source: https://www.bytebase.com/database-mcp-server/

---

## What a raw MCP server leaves wide open.

### Every agent shares one connection string

No per-agent identity, so you cannot tell which agent ran which query, or revoke just one of them.

### Full-table reads, PII included

Without masking on the read path, an agent that queries a users table sees every email, token, and secret in clear text.

### Writes reach production unreviewed

An agent can run an UPDATE or a DROP with no approval, no SQL review, and no rollback path.

## One access policy caps every agent session.

An admin with the workspace settings permission (the Workspace Admin and DBA roles have it) sets the most any MCP session may do: Disabled (no session can connect), Read-only (inspect schemas and run queries Bytebase has checked are reads), or Read-write (propose and run changes). New workspaces start at Read-only. The policy only narrows what the signed-in user's own permissions allow, it applies to sessions already connected on their next request, and no MCP session can change it. In every mode a session cannot change workspace settings, approve issues, or touch credentials. Under Read-only, a request is refused whole unless every statement is a read that returns data. https://docs.bytebase.com/integrations/mcp#access-policy

## The agent connects to Bytebase, not to the database.

### OAuth sign-in as a Bytebase user

The MCP client signs in with OAuth; the authorization page shows the workspace access policy before you click Allow. The agent never holds a database credential.

### Masking on the read path

Dynamic data masking applies to agent queries the same way it applies to SQL Editor users, on the engines Bytebase masks. A fully masked cell comes back as ******.

### Writes through review

Under Read-write, a proposed change creates a plan with plan checks and an issue that follows the project's review and approval flow. The agent never approves its own change.

### Audit with an MCP tag

Queries, exports, proposed changes, and rollouts are logged under the signed-in user with the OAuth client, the approved scope, and a per-session correlation ID. Filter with mcp == true.

## Not the same thing as DBHub.

DBHub (github.com/bytebase/dbhub) is a separate, standalone MCP server from the same team: one binary, a connection string, writable until `readonly` is set per tool, no per-agent identity, masking, or audit. Use DBHub on a laptop; use the Bytebase MCP server against production.

## Read in order.

### What is a database MCP server?

/blog/what-is-a-database-mcp-server

### Governed MCP vs. raw MCP

/blog/governed-mcp-vs-raw-mcp

### Connect an AI assistant to Bytebase with MCP

https://docs.bytebase.com/tutorials/connect-ai-assistant-with-mcp

## Get Started

- [Contact us](https://www.bytebase.com/contact-us/)
- [Start now (cloud)](https://console.bytebase.com)