# PlanetScale MCP > PlanetScale MCP Server manages serverless MySQL infrastructure dynamically via your AI agent. It lets you provision, branch, and destroy global database clusters without touching a web console. Your agent can list regions, create ephemeral test branches from production schemas, or delete stale staging environments instantly. This is for developers who need to manage high-availability data structures at scale. ## Overview - **Category:** loved-by-devs - **Price:** Free - **Tags:** mysql, serverless, database-branching, vitess, schema-management, devops ## Description **PlanetScale MCP Server - Manage MySQL Branches & Databases** Listen up: this isn't just another database connector. This gives your agent direct, programmatic control over a global, serverless MySQL cluster via PlanetScale. You can treat your entire data infrastructure like Git—meaning you can spin up isolated test environments and audit global connectivity without ever touching a web console or getting stuck in some confusing GUI dropdown. Your AI client handles the dirty work; you just tell it what to do. ### **DevOps Workflow: Branching for Safety** You need to test a schema change before you push it live, right? You don't want that risk on production. The `create_branch` tool lets your agent clone the whole schema mapping from your main database into an empty, isolated test branch. It’s consequence-free development. When you're ready to check what lives in those branches, use `list_branches` to see everything you've spun up. You can also peep at the access details for any specific environment using `get_branch`. Need to clean house? If a dev branch is stale and nobody uses it, run `delete_branch`; that wipes it out for good. ### **Global Cluster Management: Provisioning & Auditing** Managing databases across regions is hell if you gotta click around. This server lets your agent handle the core infrastructure stuff. You can get a full list of all high-availability MySQL distribution IDs across your accounts using `list_databases`, and if that's not enough, you can check out every root organizational identifier needed to connect anywhere with `list_organizations`. Want to know where the data lives physically? Use `list_regions` to locate every available cloud provider edge availability zone supported by Vitess. To actually set up or inspect a cluster, your agent uses these tools. First, you can provision an entirely new, scalable serverless MySQL instance ready for defining DDL with `create_database`. Before making any changes, check the core setup of that cluster using `get_database` to validate every setting. If you ever gotta know what’s going on globally, you can list all existing development database branches through `list_branches`, or simply see which clusters are active by calling `list_databases`. ### **Cleanup and Destruction: Making It Go Away** Nothing bugs me more than stale resources hanging around. This connector makes cleanup simple. If an entire MySQL cluster is obsolete, you can destroy it completely with `delete_database`; that wipes all associated records globally. Similarly, if a development branch is dead weight, the `delete_branch` tool takes care of it. You’ll never have to manually delete anything again. ### **How It Works in Practice** It's simple: you prompt your agent with natural language instructions—like, "Give me access details for my test branch from last week" (which uses `get_branch`), or "List all the available regions." Your agent then maps that request to the correct tool. It executes the API call directly against the live PlanetScale cluster, giving you immediate, structured feedback on whether it worked or where it failed. This means you can write complex operations—like listing regional availability (`list_regions`), creating a temporary development branch from production data (`create_branch`), and then running `get_database` to verify the settings before telling your agent to delete the cluster entirely (`delete_database`)—all in one go. It’s pure, high-speed database ops, no web console required. ## Tools ### create_branch Clones the schema mapping from the main database into an empty, isolated test branch for safe development. ### create_database Provisions a new, radically scalable serverless MySQL instance ready for DDL definitions. ### delete_branch Irreversibly deletes an obsolete development branch or schema test environment. ### delete_database Destroys a specific PlanetScale MySQL cluster entirely, wiping all associated records globally. ### get_branch Retrieves the necessary access hostnames for a specified database branch. ### get_database Analyzes and returns the core configuration details of a specific MySQL cluster. ### list_branches Lists all existing development database branches, useful for migration planning. ### list_databases Retrieves a list of high-availability MySQL distribution IDs across your accounts. ### list_organizations Lists the root organizational identifiers required to manage any endpoint connections. ### list_regions Locates all physical cloud provider edge availability zones supported by Vitess. ## Prompt Examples **Prompt:** ``` List all physical cloud regions currently exposed by the PlanetScale integration. ``` **Response:** ``` I executed `list_regions` successfully against your organization map. I found 15 edge locations. The primary North-American targets are `us-east` (AWS N. Virginia) and `us-west-2` (AWS Oregon). There are also `eu-west` endpoints available for immediate Database generation. Would you like me to create an instance there? ``` **Prompt:** ``` We're starting a new feature. Fork testing branch from the main database 'store-backend'. ``` **Response:** ``` Executed `create_branch`. Branch `feature-test-1y82` has been successfully spun up under `store-backend`. It copied the exact static schema logic from `main` without migrating standard rows, resulting in an empty, compliant Vitess environment ready for raw testing strings. What's the new DDL injection you're planning? ``` **Prompt:** ``` Drop the specific 'staging-01' branch inside the 'web-portal' database. ``` **Response:** ``` Command `delete_branch` deployed explicitly specifying target DB 'web-portal' aiming for branch 'staging-01'. The environment hook has been severed internally and queued for complete data physical destruction. Staging-01 operates out of existence as of now. ``` ## Capabilities ### Provisioning Database Clusters Instantly list, create, inspect, or destroy entire serverless MySQL clusters globally using tools like `list_databases` and `create_database`. ### Managing Schema Branches (DevOps Workflow) Use the Git-like workflow to clone a production schema into an empty, isolated branch (`create_branch`) for consequence-free testing before deployment. ### Infrastructure Auditing Query foundational data points, such as listing all organizational IDs (`list_organizations`) or finding available physical cloud edges (`list_regions`). ### Full Lifecycle Cleanup Programmatically destroy obsolete database branches (`delete_branch`) or entire clusters (`delete_database`), ensuring no stale resources linger. ### Cluster State Inspection Retrieve the core configuration details for a specific MySQL cluster using `get_database` to validate settings before making changes. ## Use Cases ### Need a clean test environment for one feature. A developer needs to test a new migration path. Instead of requesting admin time or manually setting up a clone, they prompt their agent: 'Spin up an empty branch from `main` called `feature-x`.'. The agent uses `create_branch`, providing a clean, isolated Vitess environment ready for DDL injection. ### Auditing global cluster locations. A platform architect needs to know which physical cloud edge zones are available in Europe before budgeting. They ask the agent to run `list_regions`. The agent returns a comprehensive list of all supported geographic locations, allowing them to plan for optimal latency. ### Tidying up old staging data. The team finished testing an old feature branch named `staging-01` but never deleted it. An engineer prompts: 'Destroy the `staging-01` branch in the web-portal DB.' The agent executes `delete_branch`, permanently removing the resource and freeing up resources. ### Starting a new project with a known schema. A full-stack developer needs to set up a new service. They first run `list_organizations` to identify the correct root ID, then use that ID in conjunction with `create_database` to provision an empty, scalable MySQL cluster for their new project. ## Benefits - Eliminate manual database setup. Instead of logging into a web console to provision test environments, you ask your agent to `create_database` or `create_branch`, and it handles the entire process automatically. - Audit infrastructure risk-free. Before deploying anything, run `list_regions` to see every edge zone available. This lets you plan low-latency deployments across global cloud providers. - Stop wasting time on stale data. Use `delete_branch` to purge obsolete staging environments instantly. The agent executes the command and confirms the resource is gone—no clicking required. - Control your schema lifecycle like Git. You can tell your agent to clone the production structure (`create_branch`) for testing, knowing you're working in a clean, empty environment isolated from `main`. - Get full visibility into your estate. Run `list_databases` and `list_organizations` to get an immediate map of every cluster ID and organizational boundary you manage. ## How It Works The bottom line is: Your AI client treats your data infrastructure as another resource you can manage with simple chat commands. 1. Ensure your AI client has this connector subscribed and you've provided an active PlanetScale Service Token. 2. Tell your agent exactly what you need: 'List all regions.' The agent uses `list_regions` to gather available physical edge zones. 3. Your agent returns a list of options (e.g., us-east, eu-west). You then ask it to perform the next action, like creating a database instance using `create_database` in that zone. ## Frequently Asked Questions **How do I know what regions are available before creating a database with create_database?** You must first run `list_regions`. This tool gives you the physical edge availability zones supported by Vitess, ensuring your new cluster will be provisioned in a working location. **Is it safe to delete an old test branch using delete_branch?** Yes, `delete_branch` is designed for purging obsolete Git-like schema testing grounds. It permanently severs the environment hook and destroys the associated data structures. **What should I run before creating a new MySQL cluster with create_database?** Before provisioning, you should always use `list_organizations` to resolve the foundational organizational ID. This ID is required for the agent to correctly scope your new database instance. **I need to list all existing branches before running any migrations; which tool do I use?** Use `list_branches`. It provides a clear overview of all development database branches, letting you audit which schemas are active and where your migration efforts should focus. **If I run `delete_database`, what happens to all my global records?** The command destroys the database irreversibly. It wipes terabytes of data scattered across every connected region globally, so always confirm your target first. **Must I run `list_organizations` before performing any other actions in PlanetScale?** Yes, you must list the organizations first because it resolves the foundational string key required for all subsequent MySQL endpoint management. This ID is your root access point. **What information does `get_branch` return to me?** `get_branch` returns the specific access hostnames you need for code integration. It deconstructs the layout of that single, isolated database branch so your agent knows where to connect. **What kind of data does `list_databases` provide?** `list_databases` retrieves mapping IDs for all distributed Vitess backend shards. It gives you a list of high-availability PlanetScale MySQL clusters across different regions. **Can I run destructive commands like deleting databases through this AI implementation?** Yes. The integration provides `delete_branch` and `delete_database`. They map directly to infrastructure teardowns. You should scope the Service Token carefully inside the PlanetScale dashboard to avoid catastrophic misinterpretations if your explicit intent is just testing. Deletions via `delete_database` are absolute and irretrievable. **Does `create_branch` replicate and copy my production dataset into the new branch?** No. PlanetScale branches solely duplicate the static underlying DDL structure (schema), exactly like taking a snapshot of empty tables. The new branch boots up free of rows. This design lets your agent freely run `ALTER TABLE` operations independently without crashing the master tables. **How does the agent know which organizational node I am provisioning my branches on?** All queries essentially require the foundational string parameters known as the `org_name`. If unknown, a simple `list_organizations` query reveals the UUID scope dictating your authorized account parameter bounds securely.