Connect Claude and Cursor to Your Database with MCP

The Model Context Protocol (MCP) shipped in late 2024 from Anthropic. By mid-2026 every serious AI tool supports it: Claude Desktop, Cursor, Raycast, Zed, and a long tail of clients. The promise is simple: AI gets standardized access to your tools and data without each tool reinventing the wheel.

For database work, the win is concrete. Instead of pasting \d users output into a chat, the AI reads your schema directly. Instead of guessing column names, it queries them. This post walks through how TablePro's MCP server turns that promise into something useful.

What MCP gives you#

An MCP server exposes three things to a client:

• Resources: things to read. For a database, this is the schema, table sample data, query history.
• Tools: things to call. For a database, this is run_query, explain, get_table_structure.
• Prompts: pre-written prompts the client can offer. For a database, this is "summarize this table", "find slow queries", "suggest indexes".

The client (Claude Desktop, Cursor, etc.) negotiates a connection over stdio or HTTP and gets a typed list of what's available. The user sees a tool icon in the chat, and the AI can call it like any function.

Why a database client is the right place to host this#

Three reasons:

1. Connection management is solved. Your DB credentials live in macOS Keychain via TablePro. The MCP server reuses them. No second config to keep in sync.
2. Read-only by default. TablePro's MCP server starts in read-only mode. The AI can SELECT but not DROP TABLE. You opt into write access per connection.
3. Already running. TablePro is open while you code. The MCP server lives in the same process. No new daemon, no new icon in the menu bar.

The config#

In Claude Desktop, edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "tablepro": {
      "command": "/Applications/TablePro.app/Contents/MacOS/tablepro-mcp"
    }
  }
}

Cursor uses the same shape under ~/.cursor/mcp.json. Restart the client and TablePro shows up as a tool.

That is the entire setup. No API key, no token, no daemon. The tablepro-mcp binary inside the app bundle connects to the running TablePro app over a Unix socket and pipes MCP messages through.

What the AI sees#

After connection, the AI gets:

• The list of database connections you have configured.
• For each connection, the schema (tables, columns, indexes, foreign keys).
• A run_query tool that returns rows.
• An explain tool that returns the EXPLAIN output for a query.
• An inspect_table tool that returns column types, sample rows, and row count estimates.

Crucially, the AI does NOT see your data unless you ask it to. Schema is free; rows require a query. This matches how a human approaches a database for the first time.

Example: "find duplicates in users"#

Without MCP:

You: I want to find duplicate users by email.
AI: Try `SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1`
You: It says "column email does not exist".
AI: What columns does the table have?
You: id, email_address, created_at, ...

Three round trips, and the AI is still guessing.

With MCP:

You: Find duplicate users by email.
AI: [reads schema for users] The email column is named email_address.
    [runs SELECT email_address, COUNT(*)...] 
    Found 12 duplicates. Want me to show the worst offenders?

One round trip. The AI knew the schema before it answered.

Read-only is the default for a reason#

The MCP spec lets servers expose any tool they want. A database MCP server could expose drop_table if it wanted. TablePro's does not.

Read-only by default exists because:

• AI calling a tool is fast. The user does not always have time to read the proposed action.
• Some prompts ("clean up old users") are ambiguous. The AI may interpret "clean up" as DELETE.
• Production databases are not the place for autonomous experimentation.

If you want write access, you opt in per connection. Open the connection in TablePro, toggle Allow MCP Writes, confirm with Touch ID. The MCP server then exposes run_write_query and apply_migration to that connection only.

For most workflows, read-only is enough. Schema introspection plus SELECT covers exploration, debugging, and analysis.

When MCP is not the right call#

Two cases where MCP doesn't help:

1. Mass data migration. AI calling tools one query at a time is slow. Use a real migration tool with diff and rollback.
2. Sensitive data in chat. MCP returns rows to the AI, and the AI may quote them in its response. PII, payment data, and health records do not belong in a chat transcript. Run those queries in TablePro directly.

What's coming#

A few things on the roadmap:

• Bookmarked queries as MCP "prompts" (the AI offers them as starting points).
• Per-table column-level allow/deny rules for MCP read access.
• Query budgets per session (no more 1B-row scans by accident).
• Resource subscriptions for table change notifications.

If you have feedback, the MCP source code is at TablePro/Core/Services/MCP/. The protocol is still young; the right defaults are not all decided yet.

Try it#

Install TablePro, add a database, edit your client's config:

{
  "mcpServers": {
    "tablepro": {
      "command": "/Applications/TablePro.app/Contents/MacOS/tablepro-mcp"
    }
  }
}

Restart Claude Desktop or Cursor. You should see TablePro in the tool list. Ask the AI about a table you remember the name of. The first response that quotes your real schema is the moment MCP starts feeling useful.