Database Access: SQL & NoSQL

Your AI writes a User interface from memory, and it is wrong: it guesses email is non-null, misses the deleted_at soft-delete column, and types created_at as a string when it is a timestamptz. Ten minutes later you are debugging stuck orders, and the AI cheerfully suggests a query against a payment table that is actually named payments. Both failures have the same root cause — the AI is guessing at your data instead of reading it.

A database MCP server closes that gap. Once your AI can introspect the schema and run read-only queries, two everyday workflows stop being painful: turning a real table into correct application code, and chasing a data bug with live queries instead of hand-written SQL. This page is about those two workflows. For the full menu of database MCP servers and how to install each one, see SQL and NoSQL Database MCP Servers.

What You’ll Walk Away With

• A repeatable flow for generating an exact data model from a live table, across Cursor, Claude Code, and Codex
• A live-data debugging loop that finds the offending rows in minutes
• Copy-paste prompts for both workflows
• The read-only security posture that keeps these workflows safe to run against staging

Quick setup

These workflows assume one database MCP server is connected. The minimal Postgres-via-Prisma config is below; swap in MongoDB, SQLite, or Supabase from the database MCP reference. Cursor and Claude Code share the same mcpServers JSON; Codex uses [mcp_servers.<id>] TOML where stdio is implied by command.

Cursor

{
  "mcpServers": {
    "prisma": {
      "command": "npx",
      "args": ["-y", "prisma", "mcp"]
    }
  }
}

Claude Code

claude mcp add prisma -- npx -y prisma mcp

Codex

[mcp_servers.prisma]
command = "npx"
args = ["-y", "prisma", "mcp"]

Caution

Connect with a database user scoped to read-only (SELECT) permissions, and point it at staging, not production. A server that can run arbitrary SQL can run DROP TABLE — read-only access removes that entire class of accident while you build trust in the workflow.

Workflow 1: Generate a data model from a live table

You need a User model that matches the users table exactly — not the AI’s best guess.

1. Have the AI read the real schema. Inspecting first means the generated code is grounded in the actual columns, types, and nullability.

   Tip

   Copy-paste prompt to introspect a table:

   “Use the database MCP to inspect the users table. List every column with its exact type, nullability, and default. Call out the primary key, any unique constraints, and any soft-delete or status columns. Do not generate code yet — just report the schema.”

2. Generate the model from that context. Now the AI has the truth in context, so the types line up.

   Tip

   Copy-paste prompt to generate typed code from a schema:

   “Based on the schema you just read, generate a TypeScript interface for User plus a Zod schema that validates a row from that table. Match nullability exactly (nullable columns become optional/null), map timestamptz to Date, and add a short comment on any column that is a soft-delete or status flag. Do not invent columns that are not in the schema.”

   The result matches your table because it was generated from your table — nullable columns are optional, the timestamp is a Date, and deleted_at is documented rather than dropped.

Workflow 2: Debug with live data

Some orders are stuck and you suspect the data, not the code. Instead of hand-writing a join, describe the symptom and let the AI build and run the query.

1. Describe the bad state in plain English. The AI translates it into SQL, runs it through the MCP server (read-only), and shows you the offending rows.

   Tip

   Copy-paste prompt to hunt down bad rows:

   “Using the database MCP, find every order created in the last 24 hours with status = 'pending' that has no matching row in the payments table. Return order id, customer id, created_at, and total, sorted oldest first. Show me the exact SQL you ran so I can sanity-check the join.”

   Asking it to print the SQL it ran is the difference between a black box and a tool you can trust — you verify the join logic yourself before believing the result.

2. Pivot from the evidence. With concrete order ids in hand, you can narrow further without rewriting anything by hand.

   Tip

   Copy-paste prompt to drill into a finding:

   “For those stuck orders, check the payment_attempts table for any failed attempts in the same window. Group by failure reason and count. If a single error code dominates, summarize what it means and which orders it explains.”

You diagnosed the root cause from live data without leaving the editor or hand-writing a multi-table join — and because the user is read-only, none of it could have mutated anything.

When This Breaks

The AI queries a table or column that does not exist. It is still guessing instead of introspecting. Force step 1: make it read the schema before it writes any query, and confirm the MCP server is actually connected (the client should list its tools).

It runs UPDATE or DELETE when you only wanted SELECT. The database user has too many permissions. Create a dedicated read-only role for MCP access — this is the single most important safeguard for both workflows.

Schema inspection returns stale results after a migration. Some MCP servers cache schema metadata. Restart the server to refresh the cache, then re-run the introspection prompt.

A query times out on a large table. Analytical scans can exceed the server’s tool timeout. Add an index, add a tighter WHERE clause, or ask the AI to LIMIT and paginate.

What’s Next

Database MCP Servers Full setup for Prisma, Supabase, MongoDB, SQLite, and dbhub with three-tool configs.

Building Custom MCP Servers Wrap an internal API or proprietary data store in your own MCP server.