How to Set Up a SQLite MCP Server With Gemini CLI

We use Turso (libSQL over HTTP) for our feature flag data. It's fast, it's edge-distributed, and it stores a record per user per flag, which means the table is wide and the cardinality is high. I wanted to know which flags were on for over half our users before we promoted one to default-on. I could have written the query myself. I didn't want to. I had Gemini ask for it instead.

Gemini's context window is large enough to hold a sprawling SQLite schema without losing track of which columns are booleans-stored-as-integers versus which ones are actual text fields. That matters a lot with SQLite's dynamic typing.

Part of the SQLite MCP Server guide.

What you'll need

• A SQLite database or Turso/libSQL endpoint
• A QueryBear account
• Gemini CLI installed (npm i -g @google/gemini-cli or via Homebrew)

Why route through a gateway

With a Turso endpoint, you're already working over HTTP, so it can feel like it's "just an API." But the agent still has whatever read access your auth token grants. QueryBear adds a SQL parser that rejects mutations, a table allowlist so the agent only sees what you've approved, column masking for anything sensitive, and a query log so you can see what ran. Full explanation in the SQLite MCP Server guide.

Connect QueryBear to your SQLite

1. Open the QueryBear dashboard and click "New connection."
2. Choose "SQLite / Turso" and paste your libsql://...turso.io URL plus your auth token. If you're on a plain SQLite file, use a file path.
3. Under "Allowed tables," pick the tables the agent should be able to query.
4. Under "Blocked columns," add anything you'd rather not see in terminal output. Save.

QueryBear uses @libsql/client over HTTP to reach Turso endpoints, so no special driver setup is needed on your end.

Install the QueryBear MCP server in Gemini CLI

Edit ~/.gemini/settings.json (create it if it doesn't exist):

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

Gemini CLI reads this on every invocation. Save the file and the next command you run will have the MCP server available.

Ask your first question

I asked: "Which feature flags are toggled on for over 50% of users?"

Gemini called get_schema, saw the feature_flag_assignments table with flag_name (TEXT) and enabled (INTEGER, 0 or 1), and wrote this:

SELECT
  flag_name,
  SUM(CASE WHEN enabled = 1 THEN 1 ELSE 0 END) * 100.0 / COUNT(*) AS pct
FROM feature_flag_assignments
GROUP BY flag_name
HAVING pct > 50;

QueryBear ran it through the parser, confirmed the table was on the allowlist, and returned the results. Three flags were above 50%. Gemini listed them with their percentages and noted that enabled was being treated as an integer, which was correct given the schema.

The CASE WHEN enabled = 1 pattern is the right way to sum booleans in SQLite since there's no native bool type. Gemini got there without being told, which tracks: it had seen the column type from get_schema.

A Gemini-specific tip

Because Gemini re-reads settings.json on each invocation, you can keep multiple QueryBear configs in the file and swap the active one by editing a single line. Some people maintain a querybear-staging and querybear-prod entry side by side and just rename the key they want active for that session. No restarts, no environment variable juggling. Useful if you're chasing a bug that only reproduces in staging data.

Using a different tool?

• Claude Code
• Claude Cowork
• Cursor
• Windsurf
• ChatGPT
• Codex

Querying a different database?

• Postgres MCP Server
• MySQL MCP Server