Using MCP to Let Claude and Cursor Manage Your Database (Locally)

The Model Context Protocol from Anthropic has quietly become the standard way AI assistants connect to external tools. Cursor supports it. Claude Desktop supports it. Windsurf supports it. Codex supports it. If you're using any serious AI coding assistant in 2026, you're using MCP whether you know it or not.

And one of the most useful things you can do with MCP is connect your AI assistant to your database. You ask "show me all users who signed up this week" in plain English, the AI writes the query, the query runs against your actual database, and you get real results back in the chat. No copy-pasting schema definitions. No manual SQL. No switching to a separate database tool to run the query and screenshot the result.

It's genuinely great when it works.

But there's a catch, and it's the kind of catch that makes security-conscious people close the tab and go back to doing things manually. Most MCP database servers — the official Postgres MCP, the community SQLite MCPs, the various "connect your database to ChatGPT" services — work by having the AI client connect directly to your database. That means your database credentials and your query results flow through the AI provider's infrastructure. For a local SQLite file you're using to prototype something, that's fine. For a production Postgres database with real user data, it's a non-starter for most teams.

I've been building Basevolt, a local-first desktop app for working with databases, and one of the features I shipped recently is a built-in MCP server. The idea is simple: your AI assistant (Claude, Cursor, Windsurf) connects to BaseVolt running on your machine, and BaseVolt connects to your database. The AI never sees your database credentials. The connection to your database stays local. The only thing that leaves your machine is the query results the AI needs to answer your question — and even that goes directly to the AI provider, not through some intermediate cloud relay.

This post is a practical guide to setting that up, plus a deeper look at why the local approach matters and how it compares to the alternatives.

The MCP Database Problem

Let me be specific about the problem, because "security" is too vague to be useful.

When you configure an MCP database server in Claude Desktop or Cursor, you typically point it at a server process that connects to your database. The official @modelcontextprotocol/server-postgres, for example, takes a Postgres connection string and exposes your database to the AI client as a set of MCP tools — run query, list tables, describe schema, etc.

Here's what actually happens when you ask Claude "show me the last 10 orders":

1. Claude decides to call the query tool with a SQL string.
2. Claude Desktop sends that tool call to the MCP server process running on your machine.
3. The MCP server process runs the query against your Postgres database.
4. The results come back to the MCP server.
5. The MCP server sends the results back to Claude Desktop.
6. Claude Desktop sends the results to Anthropic's API so Claude can read them and respond.

Steps 1-5 are local. Step 6 is not. The query results — your actual order data, customer names, dollar amounts, whatever — get sent to Anthropic's servers as part of the conversation context. That's how Claude can read them and respond. This is fundamental to how MCP works: the AI needs to see the results to use them.

Now, is that a problem? It depends. If you're querying a local development database with fake data, no. If you're querying a production database with real customer PII, yes — you're sending that data to a third party, possibly in violation of your data processing agreements, possibly in violation of GDPR or HIPAA or SOC 2 commitments.

But the query results going to the AI provider isn't even the worst part. The worst part is the credentials.

With a direct database MCP server, the MCP server process needs your database credentials to connect. Those credentials live in your MCP config file — usually claude_desktop_config.json or .cursor/mcp.json. They're on your disk, which is fine. But the MCP server process itself is a long-running thing that has an open connection to your database. If that process is compromised, or if the AI client is tricked into running a malicious tool call, your database is exposed.

And then there's the cloud relay variant. Some MCP database services don't run locally at all. You give them your database credentials, they connect to your database from their cloud infrastructure, and the AI client talks to their cloud service over the network. Now your credentials and your data are on someone else's server, and you're trusting them to handle both. This is somehow both more popular and more obviously problematic.

The core issue: most MCP database setups ask you to trust too many parties with too much access. The AI provider sees your data. The MCP server process has your credentials. The cloud relay service has both. For a protocol that's supposed to make AI assistants more useful, the database use case has a trust problem.

What MCP Actually Is (Quick Primer)

Before we go further, let me explain what MCP is for people who haven't dug into it. If you already know, skip this section.

MCP — the Model Context Protocol — is a protocol for AI assistants to call external tools. It's JSON-RPC based, which means it's a standardized way for an AI client (like Claude Desktop) to talk to a server process that exposes useful functionality.

The architecture is straightforward:

• The AI client (Claude Desktop, Cursor, Windsurf) is the thing you're chatting with. It runs on your machine.
• The MCP server is a separate process that exposes "tools" and "resources" the AI can call. It also runs on your machine, usually as a local process spawned by the AI client.
• The protocol is the language they use to talk to each other. The AI client sends tool calls, the MCP server executes them and returns results.

When you have a conversation with Claude and Claude decides it needs to query your database, it calls an MCP tool. The AI client forwards that call to the MCP server. The MCP server does the work and returns the result. Claude reads the result and continues the conversation.

The key thing to understand: the AI client decides when to call MCP tools. You don't manually invoke them. You just talk normally, and the AI figures out that it needs to call a tool to answer your question. This is what makes MCP feel magical — you say "show me all tables" and the AI just does it, because it knows there's a list_tables tool available.

Here's what a minimal MCP server config looks like in Claude Desktop:

{
  "mcpServers": {
    "my-database": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sqlite"],
      "env": {
        "DB_PATH": "/path/to/your/database.db"
      }
    }
  }
}

This tells Claude Desktop: "when you start up, run this command to spawn an MCP server process. Expose its tools to me as my-database." When you ask Claude a question about your database, it can call the tools that server exposes.

The protocol itself is open and well-documented. Anthropic published the spec, and there are SDKs in TypeScript and Python. Anyone can write an MCP server. That's why there are already hundreds of them — for GitHub, for Slack, for filesystems, for databases, for basically anything you'd want an AI to interact with.

The problem isn't the protocol. The protocol is fine. The problem is how database MCP servers are typically deployed, which is what the rest of this post is about.

The Three Ways to Connect AI to Your Database

There are three architectural patterns people use to connect AI assistants to databases. They look similar from the outside — you ask a question, you get an answer — but they differ significantly in where your data goes and who has access to what.

Option 1: Direct Database MCP Server

This is the most common approach. You run an MCP server process locally that connects directly to your database. The official Postgres MCP server works this way. So do most community SQLite MCP servers.

The flow looks like this:

You → AI Client (Claude Desktop) → MCP Server (local process) → Your Database

How it works: You configure the MCP server with your database connection string or file path. The server process maintains a connection to your database. When the AI calls a tool, the server runs the query and returns results.

Pros: Simple setup. One process, one config file. Works well for local databases. The official servers are open source and auditable.

Cons: Your database credentials live in the MCP server process. Query results flow back through the AI client to the AI provider. If you're connecting to a production database, you're trusting the AI provider with your data. There's no access control layer between the AI and your database — if the AI decides to run DROP TABLE users, the MCP server will happily execute it (though some servers have read-only modes).

When to use it: Local development databases, SQLite files with non-sensitive data, throwaway databases you don't mind losing. Don't use this for production.

Option 2: Cloud Relay MCP

Some services offer a hosted MCP server. You give them your database credentials, they connect to your database from their cloud, and your AI client talks to their service over the network.

The flow:

You → AI Client → Cloud Relay Service → Your Database

How it works: You create an account, add your database connection details to their web dashboard, and they give you an MCP endpoint URL to put in your client config. The AI client sends tool calls to their cloud, their cloud runs the queries, results come back through the same path.

Pros: No local process to manage. Works from any machine. The relay service can add features like query logging, rate limiting, audit trails.

Cons: Your database credentials are stored on someone else's server. Your query results pass through their infrastructure. You've added a third party to the trust chain. If their service has an outage, you lose database access from your AI tools. If they have a breach, your database credentials are in the blast radius.

When to use it: Honestly, I struggle to recommend this for databases. The security tradeoffs are hard to justify. Maybe for a read-only analytics database where the data is already public-ish, but even then, why add the intermediary?

Option 3: Local MCP Server via a Desktop App (BaseVolt)

This is the approach I built BaseVolt around. Instead of running a bare MCP server process that connects directly to your database, you run a desktop app that manages your database connections and exposes an MCP server as one of its features.

The flow:

You → AI Client (Claude Desktop) → BaseVolt (local process) → Your Database

How it works: BaseVolt is a desktop app that connects to your databases — SQLite files, Postgres, MySQL, Cloudflare D1. It manages the connections, handles credentials, and provides a UI for browsing and editing your data. It also runs an MCP server on localhost. Your AI client connects to that MCP server. When the AI calls a tool, BaseVolt executes it against your database and returns the results.

Pros: Your database credentials stay in BaseVolt, not in a config file or on a cloud server. The connection to your database is local. No cloud relay. You get an access control layer — BaseVolt can restrict what the MCP server is allowed to do (read-only, specific tables, etc.). Plus you get a full database workspace UI alongside the MCP integration.

Cons: You need to install and run a desktop app. It's one more thing on your machine. (Though if you're already using a database tool, it's not an additional thing — it's a replacement.)

When to use it: When you're working with databases you care about — production data, customer data, anything where you don't want credentials and query results flowing through random infrastructure. Which, honestly, should be most of the time.

Setting Up BaseVolt's MCP Server (Step by Step)

Let's get practical. Here's how to set up the local MCP server in BaseVolt and connect it to Claude Desktop, Cursor, and Windsurf.

Step 1: Install BaseVolt and Connect Your Database

Download BaseVolt from basevolt.app. It's available for macOS and Windows. Install it like any other desktop app.

When you open BaseVolt for the first time, it'll ask you to add a data source. You have options:

• SQLite: Point it at a .db or .sqlite file on your machine. BaseVolt reads it directly.
• PostgreSQL: Enter your host, port, database name, username, and password. BaseVolt connects over the standard Postgres wire protocol.
• MySQL: Same idea — host, port, credentials.
• Cloudflare D1: Authenticate with your Cloudflare account and select a D1 database. BaseVolt talks to the D1 REST API.

For this walkthrough, let's assume you're connecting to a local Postgres database. Enter your connection details, click connect, and BaseVolt will load your schema. You should see your tables, columns, and relationships in the sidebar.

The free tier lets you connect up to 2 data sources, which is plenty for trying this out. Pro is $99/year if you need more.

Step 2: Enable the MCP Server in BaseVolt Settings

Open BaseVolt's settings (gear icon in the bottom left, or Cmd+, on macOS / Ctrl+, on Windows). Navigate to the MCP section.

You'll see a toggle: "Enable MCP Server." Turn it on.

BaseVolt will start an MCP server on localhost. By default it picks an available port and shows you the URL — something like http://localhost:3107/mcp. Note this URL; you'll need it for the next step.

There are a few options here worth mentioning:

• Read-only mode: When enabled, the MCP server can run SELECT queries and describe schemas, but cannot create tables, modify columns, or write data. Good for production databases where you want the AI to analyze but not mutate.
• Allowed data sources: If you have multiple databases connected, you can choose which ones are exposed via MCP. Useful if you have a production database and a scratch database and only want the AI touching the scratch one.
• Port: You can fix the port if you want a stable config, or let BaseVolt auto-select.

Once the MCP server is running, you'll see a status indicator in BaseVolt showing it's active and listening.

Step 3: Configure Your AI Client

Now you need to tell your AI client where to find the MCP server. The config is slightly different for each tool, but the idea is the same: point it at the localhost URL BaseVolt gave you.

Claude Desktop

Claude Desktop uses a config file called claude_desktop_config.json. The location depends on your OS:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Open it (create it if it doesn't exist) and add a BaseVolt entry to the mcpServers object:

{
  "mcpServers": {
    "basevolt": {
      "type": "url",
      "url": "http://localhost:3107/mcp"
    }
  }
}

The type: "url" tells Claude Desktop to connect to a running MCP server over HTTP, rather than spawning a new process. This is the right choice for BaseVolt since BaseVolt manages its own server process.

If you're on an older version of Claude Desktop that doesn't support the url type, you can use the command-based config instead:

{
  "mcpServers": {
    "basevolt": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://localhost:3107/mcp"]
    }
  }
}

This uses mcp-remote as a bridge between the HTTP endpoint and Claude Desktop's stdio-based transport. Either way works.

Save the file and restart Claude Desktop. When it starts up, it should connect to BaseVolt's MCP server. You can verify this by looking at the tools available in a new conversation — you should see BaseVolt's database tools listed.

Cursor

Cursor uses a .cursor/mcp.json file in your project root (or ~/.cursor/mcp.json for a global config). The format is similar:

{
  "mcpServers": {
    "basevolt": {
      "url": "http://localhost:3107/mcp"
    }
  }
}

Cursor's MCP support has gotten more robust over the past year. The url field tells it to connect to a remote (in this case, local) MCP server. Save the file, and Cursor will pick up the config on next reload — you may need to reload the window or restart Cursor.

You can verify the connection in Cursor's settings under the MCP section. You should see basevolt listed with a green status indicator and the tools it exposes.

If you want to scope the MCP server to a specific project (so it only connects when you're working in that project), put the .cursor/mcp.json file in the project root. If you want it available everywhere, use the global config.

Windsurf

Windsurf (formerly Codeium's editor) uses a config file at ~/.codeium/windsurf/mcp_config.json. The structure mirrors Claude Desktop's:

{
  "mcpServers": {
    "basevolt": {
      "serverUrl": "http://localhost:3107/mcp"
    }
  }
}

Note the field name is serverUrl in Windsurf, not url — this has tripped me up before. Save the file and restart Windsurf. You should see the BaseVolt MCP server show up in Windsurf's MCP settings panel with its tools listed.

One thing worth noting for all three clients: the port number in these examples (3107) is just an example. Use the actual port BaseVolt shows you in its MCP settings. If you let BaseVolt auto-select the port, it might change between restarts — so either fix the port in BaseVolt's settings or update your client config when it changes.

Step 4: Start Asking Questions

Once everything is connected, open a new conversation in your AI client and just start talking to it about your database. The AI will automatically discover the MCP tools BaseVolt exposes and call them when relevant.

Here are some things to try:

"Show me all tables in the database."

The AI will call the list_tables tool, BaseVolt will return the table names, and the AI will list them out. Simple, but immediately useful if you're working with a database you didn't design.

"What's the schema of the users table?"

The AI calls describe_table with users, gets back the column names, types, and constraints, and explains them to you. No more PRAGMA table_info(users) and squinting at the output.

"Show me all users who signed up this week."

The AI figures out the right SQL — something like SELECT * FROM users WHERE created_at >= date('now', '-7 days') — calls the query tool, BaseVolt runs it, and the AI presents the results. If your users table has a different date column name, the AI will know that from the schema it already explored.

"Create a kanban view on the orders table grouped by status."

This is where it gets interesting. BaseVolt's MCP server doesn't just expose raw SQL — it exposes higher-level operations for creating views, configuring dashboards, and managing your workspace. The AI calls a create_view tool with the table name, view type, and grouping configuration. BaseVolt creates the view in its UI, and you can see it immediately in the app.

"Add a column called last_login_at to the users table."

The AI writes the ALTER TABLE statement and calls the execute tool. BaseVolt runs it. Your schema is updated. If you have read-only mode enabled, this will be blocked — which is the point.

"Generate 50 sample rows in the orders table for testing."

The AI can generate realistic sample data based on your schema — random names, dates within a range, statuses from the existing enum values. Useful when you're prototyping and your tables are empty.

The key thing is that you don't have to think about the tools. You just talk. The AI handles the translation from "show me users who signed up this week" to "call the query tool with this SQL string." That's the whole point of MCP — it abstracts the tool-calling away behind natural language.

What You Can Actually Do with AI + Your Database

Let me be more specific about the capabilities, because "query your database with AI" undersells it. Here's what you can genuinely accomplish through the MCP integration.

Query Data in Plain English

This is the obvious one. You ask questions in English, the AI translates them to SQL, BaseVolt executes the SQL, and you get answers. The AI has access to your full schema, so it knows your table names, column names, relationships, and types. It writes correct SQL because it can see the structure of your data.

Some examples I've used in practice:

• "How many orders were placed last month, broken down by status?"
• "Show me the top 10 customers by total order value."
• "Which users have a subscription that expires in the next 30 days?"
• "What's the average order value for users who signed up via referral vs. organic?"

The AI handles joins, aggregations, date math, and filtering. For complex queries, it'll often show you the SQL it's about to run before running it, which is a good sanity check.

Create and Modify Tables

The AI can write and execute DDL — CREATE TABLE, ALTER TABLE, CREATE INDEX. If you say "I need a table to track feature flags," the AI will design a reasonable schema and create it:

CREATE TABLE feature_flags (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT NOT NULL UNIQUE,
  enabled BOOLEAN NOT NULL DEFAULT 0,
  description TEXT,
  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);

It picks sensible types, adds constraints, and includes timestamps because that's good practice. You can refine it conversationally: "add a column for the percentage of users who should get the flag" and it'll alter the table.

This is where the local execution matters. The AI writes the SQL, but BaseVolt executes it locally against your database. The SQL itself goes to the AI provider (as part of the tool call), but your database credentials don't. And the execution happens on your machine, not in some cloud sandbox.

Configure Views

BaseVolt supports multiple view types on top of your tables: grid (the default table view), kanban (grouped by a status field), gallery (card-based, good for records with images), and calendar. Through the MCP integration, the AI can create and configure these views.

You can say:

• "Create a kanban view on the tickets table grouped by priority."
• "Make a gallery view of products showing the name, price, and image."
• "Set up a calendar view on events using the start_date field."

The AI calls BaseVolt's view creation tools with the right parameters. The view appears in BaseVolt's UI immediately. You can then refine it: "add a filter to only show open tickets" or "group the kanban by status instead of priority."

This is genuinely useful for non-developers who need to work with a database but don't want to learn a database tool's UI. They just describe what they want to see and the AI configures it.

Build Dashboards

BaseVolt has a dashboard feature where you can combine charts, metrics, and tables into a single view. The AI can build these from scratch.

"Make a dashboard with total signups this month, MRR, and a line chart of signups over the last 30 days."

The AI will:

1. Query your database for the relevant data.
2. Create dashboard widgets — a metric widget for total signups, a metric widget for MRR, a line chart for the signups trend.
3. Arrange them on a dashboard.

You get a working dashboard in BaseVolt without manually configuring anything. Again, you can refine: "make the chart show the last 90 days instead" or "add a breakdown by signup source."

Explore Schema Without Remembering Table Names

If you're working with a database you didn't design — an inherited codebase, a client project, an open-source app you're modifying — the schema exploration is invaluable. Instead of running \dt in psql and scrolling through table names, you just ask:

• "What tables are in this database?"
• "How does the orders table relate to the customers table?"
• "Is there a table that stores user preferences?"
• "Which tables have a foreign key to the users table?"

The AI explores the schema via MCP tools and explains it back to you in plain English. It's like having a database expert who's already familiar with your schema sitting next to you.

Generate Sample Data

When you're prototyping, you often need sample data. The AI can generate it:

"Insert 20 fake users with realistic names, emails, and random signup dates over the last month."

The AI writes INSERT statements with generated data and executes them through BaseVolt. It respects your schema — correct types, valid foreign keys, reasonable values for enum columns. This saves me probably 15 minutes every time I start a new prototype.

Why Local Matters Here

I want to spend a minute on this because it's the whole reason I built the MCP server into BaseVolt rather than just shipping a standalone MCP database server.

The three approaches I described earlier — direct MCP, cloud relay, local via desktop app — all let you do the same things. The AI can query your data, create tables, configure views. The user experience is nearly identical. The difference is entirely in where your data and credentials live.

With a direct database MCP server, your database credentials are in a config file and the MCP server process. Your query results flow from the MCP server to the AI client and then to the AI provider. The credentials exposure is limited (local process, local config file), but the data exposure is the same as any cloud AI interaction.

With a cloud relay, your credentials are on the relay service's servers. Your data flows through their infrastructure. You've added a third party to the chain. This is the worst option from a trust perspective.

With BaseVolt's local MCP server, your database credentials live in BaseVolt — encrypted, managed by the app, never exposed to the AI client or the AI provider. The connection to your database is maintained by BaseVolt locally. The AI client talks to BaseVolt's MCP server over localhost. The only thing that goes to the AI provider is the tool call results — the query results the AI needs to answer your question.

That last part is unavoidable. If you want the AI to tell you "you have 47 users who signed up this week," the AI needs to see the query result that says 47. The data in that result goes to the AI provider. There's no way around this with current AI architectures — the model needs the context to reason about it.

But here's the thing: you control what data the AI sees. You can use read-only mode. You can expose only specific tables. You can query with filters that exclude sensitive columns. The local MCP server gives you a control layer that direct database connections don't.

And the credentials never leave your machine. That's the big one. Your Postgres password, your MySQL connection string, your Cloudflare API token — they stay in BaseVolt. The AI client never sees them. The AI provider never sees them. No cloud relay sees them.

For teams with security requirements — SOC 2, HIPAA, GDPR, internal policies about third-party data access — this is the difference between "we can use this" and "we can't use this." The local approach doesn't eliminate all risk (the AI still sees query results), but it eliminates the credential exposure risk, which is the one that gets you breached.

Comparison Table

Here's a side-by-side comparison of the three approaches:

	Direct DB MCP	Cloud Relay MCP	BaseVolt Local MCP
Setup	Edit config file, install server package	Create account, add credentials to web dashboard, get endpoint URL	Install desktop app, connect database, toggle MCP on
Data flow	AI client → local process → your DB	AI client → cloud service → your DB	AI client → BaseVolt (local) → your DB
Credentials exposure	Local config file + local process	Cloud service's servers	BaseVolt app only (local, encrypted)
Works offline	Yes (for local DBs)	No	Yes (for local DBs)
Supports view/dashboard creation	No (raw SQL only)	Depends on service	Yes (kanban, gallery, dashboard, calendar)
AI assistants supported	Any MCP-compatible client	Any MCP-compatible client	Any MCP-compatible client
Access control layer	Limited (some servers have read-only mode)	Depends on service	Yes (read-only mode, per-data-source control, table-level restrictions)
Cost	Free (open source)	Usually subscription	Free tier (2 sources), Pro $99/year

The table makes it clear: if you just need to run queries against a local SQLite file and don't care about security, the direct MCP approach is fine. If you need production database access with credential protection and access control, the local desktop app approach is the only one that makes sense.

Security Considerations

I'd be irresponsible to write this post without being clear about the security tradeoffs, even with the local approach. Here's what you should think about.

The AI still sees your query results. This is the fundamental tradeoff of using any AI assistant with your data. When you ask "show me all users" and the AI calls the query tool, the result set — actual user data — goes back to the AI provider as part of the conversation. The AI needs this data to answer your question. There's no way to have the AI reason about your data without the AI seeing your data.

This means: don't ask the AI to query columns with data you don't want sent to the AI provider. If your users table has a password_hash column, don't SELECT *. Use read-only mode and restrict the exposed tables if you're concerned. Or just be thoughtful about what you ask for.

Don't connect to production databases with write access unless you trust the setup. The AI can execute DDL and DML. If you give it write access to a production database, it can drop tables, modify data, delete records. Most of the time the AI will do what you ask and nothing more. But AI models can make mistakes, and prompt injection is a real attack vector — if the AI reads a malicious prompt embedded in your data, it could execute unintended queries.

For production databases, use read-only mode. BaseVolt's MCP server supports this — it restricts the exposed tools to queries and schema inspection, no writes. This is the safe default for anything you can't afford to lose.

BaseVolt's MCP server only runs on localhost. It binds to 127.0.0.1, not 0.0.0.0. This means it's not accessible from other machines on your network, only from processes on your own machine. If you're on a shared machine or a corporate network, this matters. Nobody else can connect to your MCP server.

You can restrict what the MCP server can do. Beyond read-only mode, BaseVolt lets you choose which data sources are exposed via MCP. If you have a production database and a development database connected, you can expose only the development database to the AI. The production database stays accessible in BaseVolt's UI but isn't reachable through MCP.

Your credentials are stored locally by BaseVolt. They're encrypted at rest. They're never transmitted to the AI client or the AI provider. They're never sent to BaseVolt's servers (BaseVolt doesn't have servers that handle your database connections — it's a desktop app, everything is local). If you uninstall BaseVolt, the credentials are removed.

Audit what the AI is doing. BaseVolt logs MCP tool calls, so you can see what queries the AI has run. If something looks wrong — an unexpected DROP TABLE, a query selecting sensitive columns — you can catch it. This is something direct MCP servers often don't provide, and it's valuable for peace of mind.

The bottom line on security: the local approach is significantly better than the alternatives, but it's not magic. You're still sending query results to an AI provider. You're still giving an AI system the ability to execute SQL. Be thoughtful about what databases you connect, what access level you grant, and what you ask the AI to do.

Bottom Line

MCP is a genuinely useful protocol. The ability to ask an AI assistant questions about your database and get real answers — without copy-pasting schema definitions or manually running queries — changes how you work with data. It's one of those features that feels like a novelty until you use it for a week, and then you can't imagine going back.

But the way most people set up MCP database connections has a real problem: your credentials and data flow through infrastructure you don't control. For local development, that's acceptable. For anything that matters, it's not.

The local MCP server approach — AI client to BaseVolt to your database, all on your machine — gives you the convenience of AI-assisted database work without the credential exposure. You get the querying, the schema exploration, the view creation, the dashboard building. You don't get the security headaches.

If you're already using Claude Desktop or Cursor or Windsurf and you work with databases, this is worth setting up. It takes about five minutes, and once it's running, you'll use it constantly.

Try it at basevolt.app — no signup, no credit card. The free tier includes 2 data sources, which is enough to connect your main database and a scratch database. Install it, connect your database, enable the MCP server, point your AI client at it, and start asking questions.

If you run into issues or have questions about the setup, the demo site shows the full workflow without installing anything.

...find me on X.