How to Set Up a SQLite MCP Server With Cursor

I was debugging a flaky integration test when I noticed the errors were clustering around one endpoint. The test logs said "unexpected response," which told me nothing. What I actually needed was a count of real API errors by endpoint from today, grouped so I could see the pattern. The data was in our SQLite database running on Turso. Getting to it meant stopping what I was doing, switching contexts, and writing SQL I'd probably have to look up.

I wanted to just ask the question from inside Cursor and get back to fixing the test.

Part of the SQLite MCP Server guide.

What you'll need

• A SQLite database, including Turso/libSQL endpoints
• A QueryBear account
• Cursor installed

Why route through a gateway

Putting your database URL directly in an agent's environment means the agent can do anything your credentials allow. A gateway like QueryBear rejects anything that isn't a SELECT, applies a table allowlist, and logs every query. The SQLite MCP Server guide explains the full security model.

Connect QueryBear to your SQLite

QueryBear connects to SQLite databases via Turso/libSQL endpoints. We use @libsql/client over HTTP, so there's no need to host a sidecar or expose raw file paths. If you're running a local SQLite file, Turso's CLI can embed and sync it.

1. Open the QueryBear dashboard and click "New connection."
2. Choose SQLite/Turso, then paste your libsql://...turso.io URL and your auth token.
3. Under "Allowed tables," pick the tables the agent should be able to see.
4. Under "Blocked columns," add anything you don't want surfaced: token columns, internal flags, anything PII-adjacent. Save.

Install the QueryBear MCP server in Cursor

Cursor reads MCP config from ~/.cursor/mcp.json globally, or from .cursor/mcp.json at your project root for project-scoped config you can share via git.

Edit the file and add:

{
  "mcpServers": {
    "querybear": {
      "url": "https://mcp.querybear.com/mcp"
    }
  }
}

Restart Cursor. Open a chat window and QueryBear should appear as an available tool. You can confirm by opening the command palette with cmd-shift-P and searching "MCP" to see what's connected.

Ask your first question

Back to that flaky test. I opened a Cursor chat and asked:

"Show me API errors grouped by endpoint for today."

Cursor called get_schema through QueryBear, saw the api_logs table, and generated this query:

SELECT endpoint, COUNT(*) AS error_count
FROM api_logs
WHERE level = 'error'
  AND created_at >= datetime('now', 'start of day')
GROUP BY endpoint
ORDER BY error_count DESC;

QueryBear ran it and returned six rows. One endpoint had 94 errors. That was the one. I went back to my test, looked at that specific handler, and found the bug in about three minutes.

One thing to be aware of with SQLite: dynamic typing means a column defined as INTEGER can actually store text, and comparisons can behave unexpectedly. If you're filtering on a column and the row count looks wrong, check what's actually stored there. Explicit casts help.

A Cursor-specific tip

Commit .cursor/mcp.json to your project root. Anyone on the team who opens this repo in Cursor gets QueryBear connected without doing anything. The config file has no credentials in it (those live inside QueryBear, tied to each person's account), so it's safe to check in.

It's one of those small things that makes the team's Cursor setup feel coherent instead of each engineer having their own configuration drift.

Using a different tool?

• Claude Code
• Claude Cowork
• Windsurf
• ChatGPT
• Codex
• Gemini

Querying a different database?

• Postgres MCP Server
• MySQL MCP Server