Can the agent change schema and data, or only read it?

Yes. db_query runs read-only SQL, and db_execute handles INSERT, UPDATE, DELETE, and DDL, so an agent can both read from and modify a TiDB database, including schema changes, alongside show_databases and show_tables for introspection.

TiDB or CockroachDB for distributed SQL?

TiDB is MySQL-compatible, so it fits applications already on MySQL. CockroachDB is Postgres-compatible. The right pick follows your wire protocol; TiDB ranks second of four here and wins for MySQL-shaped workloads needing horizontal scale.

TiDB for distributed SQL

Pick 2 of 4 for distributed SQLOfficialPingCAP31

TiDB is a MySQL-compatible distributed SQL database, and PingCAP's official MCP server lets an agent explore one and run queries against it directly. It ranks second of four for distributed SQL, which is an honest placement: it is the natural pick for MySQL-shaped workloads that need to scale out, sitting a notch below the broader-tooled options for some jobs.

The seed captures the fit. If your application already speaks MySQL and you want horizontal scale without manual sharding, TiDB is where this server shines. The siblings cover other engines and wire protocols, which is why TiDB earns the runner-up slot rather than the top one across every distributed-SQL scenario.

How TiDB fits

The tools map cleanly to operating a cluster. show_databases and switch_database move between databases, show_tables lists what is in the active one, and db_query runs read-only SQL while db_execute handles INSERT, UPDATE, DELETE, and DDL. So an agent can introspect schema, read data, and apply changes against TiDB in one conversation. db_create_user and db_remove_user manage database accounts, covering basic access administration.

The honest limits: this surface is SQL execution and light user management, not cluster-health dashboards, branch or workspace tooling, or query-insight analytics. For a Postgres-compatible distributed store, CockroachDB is the right protocol match, SingleStore fits real-time analytics workloads, and PlanetScale is the pick when branch-based schema workflows on serverless MySQL matter most. Choose TiDB's server when your workload is MySQL-compatible, needs to scale horizontally, and you want an agent running SQL and schema changes against it.

Tools you would use

Tool	What it does
show_databases	Lists all databases available in the connected TiDB cluster.
switch_database	Switches the active connection to a specified database.
show_tables	Lists all tables in the current database.
db_query	Executes a read-only SQL query against TiDB and returns the result set.
db_execute	Executes data-modification SQL statements (INSERT, UPDATE, DELETE, DDL) against TiDB.
db_create_user	Creates a new database user in TiDB.
db_remove_user	Removes an existing database user from TiDB.

Full TiDB setup and config →

FAQ

Can the agent change schema and data, or only read it?: Yes. db_query runs read-only SQL, and db_execute handles INSERT, UPDATE, DELETE, and DDL, so an agent can both read from and modify a TiDB database, including schema changes, alongside show_databases and show_tables for introspection.
TiDB or CockroachDB for distributed SQL?: TiDB is MySQL-compatible, so it fits applications already on MySQL. CockroachDB is Postgres-compatible. The right pick follows your wire protocol; TiDB ranks second of four here and wins for MySQL-shaped workloads needing horizontal scale.