Stop context-switching to manage your distributed SQL infra

I remember the old days of manual scaling. You'd jump into a CLI, check your metrics, realize you needed another node or a capacity adjustment, log into a web console, navigate three layers deep into some proprietary dashboard, and hope you didn't click the wrong thing while trying to find a specific cluster ID.

Now we have AI agents. But most people are using them wrong. They treat Claude or Cursor as just better search engines for code, rather than giving them hands.

If you're running high-availability workloads on something like TiDB Cloud, the friction isn't in writing the SQL—you already know how to do that. The friction is in the operational visibility: knowing exactly what’s happening across your serverless instances versus your dedicated clusters without leaving your IDE.

The Gap Between Code and Infrastructure

The reason I spend so much time building things like MCPFusion is precisely because of this disconnect. An LLM might help you write a complex join perfectly, but if it doesn't know whether the target TiDB X instance is actually healthy or which project ID handles your staging environment, it's basically flying blind.

You end up copy-pasting JSON blobs from your terminal into the chat window just to give the model context. That's slow, prone to error, and frankly, beneath what modern tooling should look like.

This is why we released the TiDB Cloud (Serverless Distributed SQL) MCP server on Vinkius. It closes that loop.

What This Actually Does (And Doesn't)

Let's be very clear about what this tool allows you to do through an agent like Claude or Cursor. We aren't looking for "magic" here; we want predictable utility.

The current implementation focuses on discovery and inspection. In DevOps terms, it provides a controlled read-only view of your topology. Here is what's available:

• Organization Discovery: You can call list_projects to see everything sitting under your umbrella and pull metadata via get_project. This solves the "what was that project ID again?" problem immediately.
• Tier Awareness: You can differentiate between your Serverless components and your heavy lifters by using list_instances (which pulls TiDB X instances including Starter, Essential, and Premium) and list_clusters (for those Dedicated setups).
• Topology Audits: Instead of clicking around the UI to verify configurations, you ask: "Get the details for dedicated clusters in project 103." The agent uses the internal tools to report back on node counts (TiKV/TiDB) and health status.

A common mistake when people first play with MCP is assuming they can perform destructive actions immediately. To keep this production-grade and safe—especially given how I approach security with our V8 sandboxed execution contexts—this specific server is restricted to read operations. You won't accidentally wipe a production cluster because an LLM hallucinated a delete command. It identifies projects, lists instances, and monitors clusters.

The Workflow Shift

You go from this:

1. Open Browser -> Log into TiDB Cloud.
2. Navigate Project -> Find Cluster -> Note Instance Status/ID.
3. Switch to VS Code -> Write Query/Config.
4. Realize ID was wrong -> Repeat Step 1.

To this:
"Hey Claude, show me all TiDB X instances in my Production project so I can check their region status."
(Agent executes list_projects, finds ID, executes list_instances, reports result.)
"Great, now tell me if my 'Analytics-Main' dedicated cluster has enough nodes working properly."
(Agent executes list_clusters, parses response.)
everything happens inside the context of where you are actually working.

A key detail most people miss when skimming documentation is how easily you bridge individual units vs entire architectures. Because this integrates both list_instances for TiDB X and list_clusters for Dedicated builds, you aren't forced into a single mental model of "how my DB looks." You handle both serverless flexibility and dedicated stability through one unified conversational interface.

ichineering reliability means reducing entropy. Reducing entropy usually means reducing the number of times a human has to manually translate information from one system (the Console) to another (the IDE). Making infrastructure observable through an agent isn't about being lazy; it's about maintaining focus during critical deployment windows.
iof course, if you prefer doing things manually via certain enterprise GUIs instead having an agent assist your workflow through specialized protocols like MCPFindability resides in minimizing that handoff latency alone.

---

MCPs are the music of AI Agents. We built the catalog. Discover Vinkius MCP Catalog.