View Categories

How to Connect SQLite to Claude / Cursor via MCP (SQLite MCP Server Setup)

26 min read

MCP SERVER SQLITE

Query SQLite with Claude or Cursor via MCP.

Ask plain-English questions about any .db, .sqlite, or .sqlite3 file — app caches, IoT logs, dev/test fixtures, embedded analytics — over a secure, outbound-only cloud link, with Schema Intelligence baked into the SQLite MCP connector so the AI writes correct SQL on the first try.

No firewall holes One key, every connector Live data, no cache lag Bring your own AI tool

Query Streams is a secure, real-time data integration platform that brings every database and SaaS API in your account into Claude, Cursor, ChatGPT, and Grok — through a single MCP key with no firewall changes. This guide walks through wiring up the SQLite MCP connector specifically, so your AI tool can answer plain-English questions about any .db, .sqlite, or .sqlite3 file you have on disk — app event logs, IoT sensor caches, mobile-app sync stores, dev/test fixtures, embedded analytics — without you copy-pasting CSV exports out of DB Browser for SQLite, DBeaver, or the sqlite3 CLI. Learn more at QueryStreams.com and sign up for free to start asking your AI tool real SQLite questions.

What Query Streams MCP gives you for SQLite

Other “SQLite MCP” servers on the open-source landscape connect the AI tool directly to a local .db file path on the same machine. That works for the developer who owns that one file, but it ties the AI tool to one process on one machine, gives you no audit trail of what the AI asked, and breaks down completely when the SQLite file lives on a server, an IoT gateway, an embedded device, or in any environment where the AI client doesn’t have local filesystem access. The Query Streams MCP server for SQLite solves a wider problem: one key reaches every .db file the Network Agent can see, the AI tool never holds the file path, and every read is audited.

Zero inbound firewall holes

The Network Agent opens a single outbound encrypted cloud link to Query Streams. Your AI client connects to the cloud, never to the host where your .db file lives. No port to open, no IP to allowlist, no VPN, no SQLite file shared over SMB / NFS just so an LLM can read it.

One key, every connector

The same MCP key reaches every database and SaaS API your account has connected. Register multiple SQLite files (app.db, analytics.sqlite, cache.sqlite3) and the AI tool picks the right one by name — alongside any other connector you add later, no re-keying.

Schema Intelligence baked in

The AI sees AI-curated descriptions, semantic types, enum value lists, and discovered foreign keys for every SQLite column — not just PRAGMA table_info output. Critical for SQLite, where integer-encoded Unix timestamps, 0/1 booleans, and JSON blobs in TEXT columns are easy for an LLM to misread.

Read-only enforced at the agent

Even a hallucinating LLM can’t issue DELETE, UPDATE, or DROP TABLE through Query Streams MCP. The Network Agent opens your .db file in read-only mode and rejects anything that isn’t SELECT, WITH, or EXPLAIN — safe to run alongside whatever app owns the file in WAL mode.

Per-key rate limits

Default 60 requests per minute and 10 execute calls per minute, configurable per key. A runaway AI tool-call loop hits a token bucket, not the disk where your SQLite file lives or the app that’s writing to it.

How it works without opening firewall ports

The Query Streams Network Agent installs once on a machine that can read your SQLite file (a laptop, on-prem server, IoT gateway, or any host with outbound HTTPS) and dials one outbound TLS link to the cloud — nothing inbound is ever exposed, and the AI tool never sees the .db file path. how the outbound-only connection works →

AI Client

Cursor, Claude,
ChatGPT, Grok

QS MCP Server

Streamable HTTP
X-MCP-Key auth

Network Agent

On your network
Cloud link out

SQLite database

.db / .sqlite /
.sqlite3 file

No inbound port required — the agent dials out, never the other way around

The MCP key you give Cursor or Claude is scoped (read / analyze / execute), revocable at any time, and rate-limited per-key. The AI tool calls these MCP tools to do its work:

querystreams-mcp · tool catalog
qs_list_organizationsread
Returns the org bound to the calling key.
qs_list_agentsread
Lists Network Agents and online state.
qs_list_connectorsread
Lists data connectors (one entry per database server or API).
qs_get_connector_schemaread
Returns the SQLite tables, views, and columns the AI can query, with Schema Intelligence enrichment when available.
qs_profile_tableanalyze
Sample values, distributions, enum detection, semantic types — on demand.
qs_list_saved_queriesread
Pre-built parameterized SQL templates the team trusts. The AI runs them without ever seeing the SQL.
qs_run_saved_queryexecute
Executes a saved query by pattern_key with optional parameter overrides.
qs_run_queryexecute
Executes a SELECT against a connector. Read-only validator runs at the agent, before the .db file is ever opened.

Why Schema Intelligence makes Query Streams MCP different

Most “MCP for SQLite” servers in the open-source landscape hand your AI tool the bare PRAGMA table_info output SQLite gives a stranger. Column names. Storage classes (INTEGER, TEXT, REAL, BLOB). Maybe a primary key. The LLM is left to guess that events.timestamp is a Unix epoch integer (not an ISO date), that feature_flags.is_enabled is a 0/1 boolean (not a tinyint), or that events.event_type is actually a five-value enum hiding inside a TEXT column. SQLite’s permissive type affinity makes this worse than any other database — storage class doesn’t tell you what’s actually in the column.

Query Streams MCP returns that same schema enriched with Schema Intelligence (SI) — AI-curated metadata profiled from your actual SQLite data so every schema tool the AI calls returns six layers of curated knowledge on top of the bare schema, and the LLM stops guessing. how Schema Intelligence enriches every schema call →

To make this concrete, here is what the AI client gets back from a single qs_get_table_schema call against a typical SQLite application-analytics database (events, users, sessions, feature_flags) — first without Schema Intelligence, then with it.

Without Schema Intelligence data_source: captured_schema
// what the LLM sees == TABLE: events == – id INTEGER [PK, NOT NULL] – user_id INTEGER NOT NULL – event_type TEXT NOT NULL – timestamp INTEGER NOT NULL – properties TEXT == TABLE: users == – id INTEGER [PK] – email TEXT – created_at TEXT == TABLE: sessions == – id INTEGER [PK] – user_id INTEGER – duration_seconds INTEGER == TABLE: feature_flags == – id INTEGER [PK] – flag_name TEXT – is_enabled INTEGER Foreign Keys: (none declared) si_recommendation: state: “not_run” what_youre_missing_for_this_call: – AI-discovered foreign keys – Per-column sample values + enum detection – Integer-encoded date and boolean flags – Table and column descriptions – Semantic type classifications note: “storage class only, no semantic context”
With Schema Intelligence data_source: schema_intelligence
// what the LLM sees == TABLE: events [FACT, domain:product_analytics] == “User-action telemetry; one row per event. timestamp is Unix epoch seconds.” – id INTEGER [PK] identifier – user_id INTEGER identifier FK -> users.id (100% overlap, conf 0.99) – event_type TEXT status_code (enum) signup (8%) | login (41%) | view (38%) | purchase (9%) | logout (4%) – timestamp INTEGER date_unix_epoch Use datetime(timestamp,’unixepoch’). Range: 2025-11-01 to 2026-05-06 – properties TEXT json_blob (nullable) Sample: {“page”:”/pricing”,”ref”:”google”} == TABLE: users [DIM, domain:identity] == – email TEXT email Sample: [email protected], [email protected] – created_at TEXT date_iso (string) Sample: ‘2026-02-14T09:31:08Z’ == TABLE: sessions [FACT, domain:product_analytics] == – user_id INTEGER identifier FK -> users.id (97% overlap, conf 0.94) – duration_seconds INTEGER duration_seconds Range: 3 – 7,210 · mean 412 == TABLE: feature_flags [LOOKUP, domain:configuration] == – flag_name TEXT identifier Sample: [‘new_checkout’,’dark_mode’,’beta_search’] – is_enabled INTEGER boolean (0/1) Distribution: 0 (62%) | 1 (38%) — treat as boolean

The six layers Schema Intelligence adds

Each layer addresses a class of question the LLM would otherwise guess at. The opt-in SI profiling pass runs against your SQLite data without changing your schema — it opens the .db file read-only and never writes to it. what Schema Intelligence adds and how it stays current →

AI-curated descriptions

Plain-English purpose for every database, table, and column — generated once, refreshed when your schema changes. Confidence-scored; user-authored descriptions always win.

events: “User-action telemetry;
one row per recorded event.”

Table classifications

Each table tagged FACT (transactional events), DIM (descriptive reference), or LOOKUP (small code maps), plus a business domain — product_analytics, identity, configuration, sales, finance, and 14 more.

events [FACT, domain:product_analytics]
feature_flags [LOOKUP, domain:configuration]

Semantic types per column

Eighteen types — currency, email, date_iso, date_unix_epoch, status_code, boolean, json_blob, identifier, and more. Critical for SQLite, where storage class doesn’t tell you whether an INTEGER is a count, a Unix epoch, or a 0/1 flag.

timestamp: date_unix_epoch
is_enabled: boolean (0/1)

Sample values from real data

Random rows surfaced to the LLM so it recognises patterns no schema can show — JSON shapes inside TEXT columns, ISO-8601 vs Unix epoch date encodings, and the actual values your app writes.

properties: {“page”:”/pricing”,
“ref”:”google”}

Enum detection with distributions

Low-cardinality columns (50 or fewer distinct values, at most 5% of rows unique) mapped to their full value list with row counts. The AI never guesses casing or spelling on event-type tags or flag names.

event_type: signup (8%) | login (41%)
| view (38%) | purchase (9%) | logout (4%)

Implicit foreign-key discovery

Cross-table data overlap analysis finds joins that aren’t declared as DDL constraints — common in SQLite where PRAGMA foreign_keys is often off and FKs are enforced by app code, not by the database.

events.user_id -> users.id
(100% overlap, conf 0.99)

Same prompt, different SQL

The proof is in the SQL the AI tool actually writes. Same Cursor session, same Claude model, same prompt — “Which users had the most activity this week, and what features did they use?” Without Schema Intelligence the LLM has to guess. With it, the LLM knows.

Without Schema Intelligence
— LLM’s first attempt against bare schema: SELECT user_id, event_type, COUNT(*) AS n FROM events WHERE timestamp >= ‘2026-04-29’ GROUP BY user_id, event_type ORDER BY n DESC LIMIT 10 timestamp is INTEGER (Unix epoch), not text string compare to ‘2026-04-29’ returns nothing no JOIN — result has IDs, not user emails “this week” hardcoded — not dynamic no enum awareness — could miss valid event_types silently returns 0 rows; LLM has no idea why
With Schema Intelligence
— LLM’s first attempt with SI enabled: WITH active AS ( SELECT e.user_id, e.event_type, COUNT(*) AS n FROM events e WHERE e.timestamp >= strftime(‘%s’,datetime(‘now’,‘-7 days’)) GROUP BY e.user_id, e.event_type ) SELECT u.email, a.event_type, a.n AS events_this_week FROM active a JOIN users u ON u.id = a.user_id ORDER BY a.n DESC LIMIT 10 10 rows. Correct first try. timestamp seen as date_unix_epoch FK discovery surfaced events.user_id -> users.id enum-aware: kept all 5 event_type values SQLite-idiomatic datetime(‘now’,’-7 days’)
Don’t want to run Schema Intelligence? MCP still works — schema tools return bare metadata (types, primary keys, formal foreign keys, indexes) and every degraded response carries an si_recommendation block telling the AI what it’s missing, including a one-call option to enable SI mid-conversation via qs_request_si_analysis. how Schema Intelligence runs and how long it takes →
Nova AI

MCP not for you? Try Nova AI instead.

Skip the JSON config entirely: Nova AI is built into the Query Streams web portal and asks the same plain-English questions across your SQLite connector and every other connector on your account — same agent, same read-only enforcement, same Schema Intelligence, no MCP plumbing.

Meet Nova AI

Prerequisites

Before you start, make sure you have:

  1. A free Query Streams account at my.querystreams.com.
  2. The Query Streams Network Agent installed on a machine that can read your .db file — see Download the Query Streams Agent.
  3. A SQLite connector configured against the agent — see the existing connector setup guides for pointing the agent at your .db, .sqlite, or .sqlite3 file. The agent holds the file path; the AI tool never sees it.
  4. Any MCP-capable AI client. We’ll show Cursor, Claude Desktop, ChatGPT, and Grok in this guide; if you use Windsurf, Zed, Continue, Cline, VS Code Copilot, Codex, or Goose, the config block is essentially the same.
  5. Five minutes.
You only set up the agent once. The same agent that powers Query Streams’ Excel and Google Sheets add-ons, the web Query Builder, and Nova AI also serves MCP. Adding MCP to an existing Query Streams account is just generating a key — the agent and SQLite connector are already running.
1

Generate an MCP key

From the /mcp page in Query Streams, mint a key with the scopes you want.

2

Drop it into your AI client

One JSON snippet for Cursor, Claude, ChatGPT, or Grok. Same key everywhere.

3

Ask a question

“What were our top 10 customers by lifetime value?” — the AI calls the right tools, you get the answer.

Step 1: Generate an MCP key in Query Streams

Sign in to Query Streams and open the MCP page (or sign in first at my.querystreams.com and click MCP in the left navigation). Click Generate key, give the key a recognizable name (something like cursor-laptop or claude-desktop), and pick the scopes you want this key to have:

  • read — the AI can browse connectors and read schema. Required for everything else.
  • analyze — the AI can profile tables and discover relationships (sample values, distributions, semantic types). Optional but strongly recommended for SQLite work, where understanding integer-encoded dates, 0/1 booleans, and JSON-in-TEXT columns matters before the LLM writes joins.
  • execute — the AI can actually run SQL. Without this, the AI is read-only against schema metadata only.

For a typical “let Claude analyse my SQLite data” workflow, all three scopes are appropriate. For a key you’re handing to a teammate or a less-trusted client, drop execute and let them browse only. You can revoke any key at any time from the same page; the AI client will see MCP_KEY_REVOKED on its next call and stop working immediately. There’s no propagation delay.

Copy the key now — Query Streams shows it once, then stores only a hash. If you lose it, generate a new one. The key looks like qsmcp_ followed by 48 random characters and is what your AI client sends in the X-MCP-Key request header.

Step 2: Add Query Streams MCP to your AI client

The configuration is the same shape across every MCP-capable client — an MCP server entry pointing at https://mcp.querystreams.com with your key in the X-MCP-Key header. Pick your client below.

Cursor
Cursor ~/.cursor/mcp.json
// Edit ~/.cursor/mcp.json
{
  "mcpServers": {
    "querystreams": {
      "url": "https://mcp.querystreams.com",
      "headers": {
        "X-MCP-Key": "qsmcp_PASTE_KEY_HERE"
      }
    }
  }
}
Claude Desktop
Claude Desktop claude_desktop_config.json
// Settings → Developer → Edit Config
{
  "mcpServers": {
    "querystreams": {
      "url": "https://mcp.querystreams.com",
      "headers": {
        "X-MCP-Key": "qsmcp_PASTE_KEY_HERE"
      }
    }
  }
}
ChatGPT
ChatGPT Apps & Connectors
// Settings → Apps & Connectors → Add MCP
Server URL  https://mcp.querystreams.com
Auth header X-MCP-Key
Header value qsmcp_PASTE_KEY_HERE

// Requires a paid ChatGPT plan
// (Plus / Pro / Team / Enterprise).
Grok
Grok Remote MCP Tools
// Grok → Settings → Tools
{
  "mcp_servers": [{
    "name": "querystreams",
    "url": "https://mcp.querystreams.com",
    "auth_header": "X-MCP-Key",
    "auth_value": "qsmcp_..."
  }]
}

Restart your AI client. On its next start it will discover the eight Query Streams MCP tools listed above and surface them in its tool palette. In Cursor and Claude Desktop you can verify by typing “list connectors” — the AI should call qs_list_connectors and return your SQLite connector along with anything else you have configured.

Step 3: Ask the AI a SQLite question

You don’t write SQL — the AI does. You ask a question, the AI picks the right MCP tool, the agent opens the .db file in read-only mode, runs the query, and the answer comes back as text plus tables. Three example prompts to try first:

“Show me daily active users for the last 30 days.”
Engagement
The AI will call qs_get_connector_schema to discover the events, users, and sessions tables, then qs_run_query with a SELECT that uses SQLite-idiomatic date math — date(timestamp, 'unixepoch') for the day bucket, datetime('now', '-30 days') for the lower bound — COUNT(DISTINCT user_id) per day. Schema Intelligence taught it that events.timestamp is a Unix epoch INTEGER, not a string, so the date filter actually returns rows. You’ll see the DAU trend inline as a table plus a written interpretation that calls out the weekend dip and any unusual spikes.
“Which features have the highest engagement rate?”
Product
The AI joins events to feature_flags on the JSON properties column (using json_extract(properties, '$.feature')), filters feature_flags.is_enabled = 1 via Schema Intelligence’s boolean-detection on the 0/1 INTEGER column, and computes engagement rate as COUNT(DISTINCT user_id with event) / COUNT(DISTINCT user_id total). The result is a ranked feature list — the AI typically calls out which features need promotion and which look like dead weight. SI’s enum-detection on event_type means it doesn’t accidentally exclude valid event names by guessing casing.
“List the users who haven’t logged in in 60 days.”
Retention
The AI writes a CTE that finds each user’s last login event — MAX(timestamp) FILTER (WHERE event_type = 'login') grouped by user_id — then filters to users where datetime(last_login, 'unixepoch') < datetime('now', '-60 days'), joins back to users to get email and signup date. The result is a focused list sorted by oldest-last-seen, plus a written interpretation that flags cohorts most at risk of churn. You can drill in by asking “how does that compare to our 30-day window?” and the AI re-runs with the new bound.

The first time the AI calls a tool, your client may pop up a confirmation prompt asking you to approve the tool call — that’s MCP’s standard consent flow, not anything Query Streams adds. Approve once and the AI proceeds with the rest of the conversation freely. You can revisit the consent at any time in your client’s settings.

Honest billing notice: MCP usage is charged on uncompressed bytes

Query Streams’ Excel add-in, Google Sheets add-on, web Query Builder, and Nova AI all run over our compressed cloud link — we measure and bill compressedBytes against your data realm. The MCP transport (Streamable HTTP per the official MCP spec) does not reliably support compression end-to-end across every client and intermediate proxy, so we measure and bill uncompressedBytes for MCP traffic.

  • What this means: a 500 KB SQLite event-log query costs ~500 KB of your data realm when fetched via MCP, vs. ~80–120 KB via Excel / Sheets / Nova / the Query Builder. A 5,000-row event aggregate that lands as ~750 KB of JSON over MCP would have been ~120–150 KB of LZ4-compressed bytes through the Excel / Sheets / Nova / Query Builder clients — SQLite app data with repeated event-type strings compresses ~5x via LZ4. Same data, different transport, different billable size.
  • What this isn’t: a markup or a punishment for using MCP. We pass through actual bytes shipped. The other clients are cheaper because compression works reliably on those transports; we don’t punish you for the protocol choice, but we have to be transparent about the cost shape.
  • What you can do: for very large recurring queries (e.g. dumping the full events table for archival), prefer the Excel / Sheets / Nova path. For interactive AI tool calls (the typical 100–5,000 row SQLite response that fits in an LLM context), MCP is the right choice and the cost difference is in cents.

Frequently asked questions

Do I need to open ports or run a VPN to use this? +
No inbound rules, port-forwarding, NAT punchthrough, or VPN — the Network Agent makes one outbound TLS connection (port 443) and your AI client reaches https://mcp.querystreams.com from the public internet, so if outbound HTTPS works on the agent host, MCP works. See how the outbound-only connection works →
Which AI tools can I use with Query Streams MCP? +
Any client that speaks the open Model Context Protocol — Claude Desktop, Claude Code, Cursor, ChatGPT (paid), Grok, Gemini CLI, Windsurf, Zed, and 500+ more. Bring your own AI tool; you don’t have to switch. Full list of supported AI clients →
Can I revoke an MCP key? +
Yes — three independent kill-switches (per-key from the /mcp page, per-org via plan settings, and platform-level), none of which need a database password rotation or agent restart. More on MCP key security →
How is MCP usage billed against my data realm? +
MCP execute calls deduct from the same data-realm budget your Excel, Google Sheets, web Query Builder, and Nova AI usage already draws on — one consumption budget across every access method. The size measured for MCP differs. The other clients run over our compressed cloud link (we bill compressedBytes); MCP runs over Streamable HTTP, which doesn’t reliably support compression end-to-end through every client and proxy, so we bill uncompressedBytes. A 500 KB SQLite event-log query returned to Excel typically costs ~80–120 KB of your data realm; the same 500 KB result returned to Cursor over MCP costs ~500 KB. We’re transparent about it because we’d rather you know up front than be surprised at the end of the billing cycle.
Does Query Streams MCP work with my .db / .sqlite / .sqlite3 file? What about WAL mode and multi-process access? +
Yes — the Network Agent opens any SQLite 3.x file (regardless of extension — .db, .sqlite, .sqlite3, or no extension at all) via the standard sqlite3 driver. The connector is the file path, not a server URL, so anything the agent’s user can read on disk is fair game. WAL mode (Write-Ahead Logging) is supported out of the box. The agent opens the file in read-only mode by default (mode=ro in the URI), so it’s safe to run alongside whatever app owns the file — your application can keep writing while the AI reads, and vice-versa. For multi-process scenarios, the agent uses SQLite’s shared-cache mode plus a configurable busy-timeout (default 5 seconds) so brief writer locks don’t trip “database is locked” errors. Tip: register each .db file as a separate connector and you can run many SQLite databases off one MCP key — app.db, analytics.sqlite, cache.sqlite3, session.db, all visible to the LLM by name. The agent supports networked filesystems too (SMB, NFS, EFS), but for best performance keep the .db file local to the agent host.
How does this differ from running an open-source SQLite MCP server myself? +
A direct SQLite MCP server (community projects on GitHub do exist, mostly thin wrappers around sqlite3) is one MCP per .db file path on the AI client’s local filesystem. That works on a developer’s laptop, but it falls apart the moment the SQLite file lives on a different machine, an IoT gateway, or any environment where the AI client doesn’t have local filesystem access. To get Claude reading from your SQLite app log + Google Search Console + your Stripe account + your Snowflake warehouse you’d need four MCP servers configured separately in every AI client, each with its own scope model, each with its own audit story. Query Streams MCP is one key reaching every connector your account has paired — the SQLite file lives on whatever machine the agent is running on, not on the AI client’s machine. You also pick up Schema Intelligence (critical for SQLite’s permissive type affinity), agent-layer read-only enforcement, per-key rate limits, audit trail in event_logs, and the same data-realm billing pipeline you already use — none of which a direct SQLite MCP gives you.
What happens if the AI tries to write or delete data? +
It’s rejected at the agent before the .db file is ever opened for writing. Every qs_run_query call is parsed by a hardcoded read-only validator that allows only SELECT, WITH, and EXPLAIN statements; anything else returns READONLY_VIOLATION and never reaches SQLite. The validator runs in the agent process on your machine, not in the cloud, so a compromised cloud surface couldn’t bypass it. SQLite belt-and-suspenders: the agent additionally opens the file with ?mode=ro in the connection URI, so even if a malicious caller did smuggle a write past the parser, the SQLite library itself would refuse the operation. Two independent layers of read-only enforcement — one at the validator, one at the file handle.
Can I see what the AI actually asked? +
Yes. Every MCP tool call writes a row to Query Streams’ own event_logs table with the org, user, key, scope, latency, and result code. The org-admin can answer “who used MCP last week, which connector, and what did they ask?” with a single query. Note that we log the tool name and metadata, not the SQL text or returned rows — those flow through the cloud link and never land in cloud logs. SQLite-specific audit caveat: SQLite has no native server-side audit log (it’s an embedded library, not a server), so for full SQL-text capture you have two practical options: (a) enable application-level logging in whatever app owns the file — most ORMs and SQLite wrappers can emit a debug log of every prepared statement; or (b) wrap your application’s SQLite handle with the sqlite3_trace_v2 or sqlite3_update_hook C-API callbacks (and equivalents in Python’s sqlite3.set_trace_callback, Node’s better-sqlite3 hooks, etc.) to log every statement to a file. For Query Streams MCP specifically, the event_logs trail is usually sufficient — it’s tied to the AI’s identity, scope, and key, which is exactly what an audit usually needs.
Do I have to run Schema Intelligence to use Query Streams MCP? +
No — Schema Intelligence is opt-in per (connector, database) pair, and MCP works fine without it. The AI gets bare schema (storage classes, primary keys, formal foreign keys when PRAGMA foreign_keys = ON, indexes) and writes basic queries. With SI enabled, the AI gets six additional layers of curated metadata: (1) AI-curated descriptions on every table and column; (2) table classifications (FACT for transactional events, DIM for descriptive reference, LOOKUP for small code maps) plus a business domain tag (product_analytics, identity, configuration, sales, finance, and 14 more); (3) a semantic type on every column — especially valuable for SQLite, where the same INTEGER storage class can be a count, a Unix epoch, a 0/1 boolean, or a foreign key, and where TEXT can hold an ISO-8601 date string, an email, a UUID, or a JSON blob; (4) sample values from your real data so the LLM recognises the JSON shape inside a TEXT column; (5) enum detection with full value distributions on low-cardinality columns like event_type or flag_name; and (6) AI-discovered foreign keys based on cross-table data overlap, surfaced through qs_get_relationships — particularly important for SQLite databases where formal foreign-key enforcement is often disabled. Without SI, every schema-tool response also carries an si_recommendation block listing exactly what’s missing for the call — the AI can read this and offer to trigger SI mid-conversation via qs_request_si_analysis. Run time scales with table count: a small database under 100 tables completes in around 10 minutes; a typical mid-size database (a few hundred tables) finishes in 15–25 minutes; a large enterprise database with 1,500+ tables can take 45–60 minutes for a full scan. Most application-grade SQLite files (under 50 tables) finish in well under 10 minutes. SI runs through your Network Agent against your data (never in the cloud), never writes to your .db file, never changes your schema, and refreshes incrementally when your schema changes. The end-to-end effect: with SI enabled, your AI client writes correct SQL on the first try far more often than it does against any “MCP for X” server that just hands the LLM PRAGMA table_info.
What if I add another connector later, like Stripe or PostgreSQL? +
Nothing changes client-side — the same key reaches the new connector the moment the agent pairs it (qs_list_connectors picks it up automatically). One config block buys your whole account, present and future. Why one key covers every connector →
Do I have to set up MCP just to chat with my data? +
No — Nova AI is built into the Query Streams portal and works against every connector (SQLite included) with no MCP setup or config files. Use Nova to chat with your data inside Query Streams; use MCP when you want your own AI client (Claude, Cursor, ChatGPT, …) to reach the same data — same agent, same connectors, same Schema Intelligence underneath. Learn more about Nova AI →

Get started

Connect your AI tool to your SQLite data in five minutes.

One MCP key reaches every .db file the agent can see, every other database, and every API connector in your Query Streams account — with full audit trail, per-key rate limits, and zero firewall changes. Claude, Cursor, ChatGPT, and Grok all work out of the box.

Related guides: Download the Query Streams Agent | Database Connector Setup | All MCP Server guides | Nova AI text-to-SQL

Category: MCP Server

Tags: mcp, claude, cursor, sqlite, database, developer-tools, embedded-database

Meta Description: Connect SQLite (.db / .sqlite / .sqlite3) to Claude or Cursor via Query Streams MCP. Outbound, read-only, 5 min.

Updated on June 16, 2026

Powered by BetterDocs