AI Assistants via MCP

DBConvert Streams ships an MCP (Model Context Protocol) server that lets your AI assistant inspect databases, schemas, files, and stream state through the same workspace you already use. It reads from your existing connections and never writes — the AI can look and advise, but can't change anything.

What it gives you

Without MCP, you copy-paste schemas, error messages, and query results into chat windows — and they go stale the moment something changes. With MCP, your AI assistant calls DBConvert Streams directly and always works from live state: the same connections, schemas, files, and stream status you see in the app.

Because the AI reads through the workspace that already powers Data Explorer, it sees exactly what you see — no separate credentials, no second copy of your schema to keep in sync.

Quickstart

Connect by how DBConvert Streams runs:

• Desktop app → stdio: open the ✨ AI Assistants panel, click Connect next to your client, and restart it.
• Docker (local or remote) → HTTP: point your client at http(s)://<host>/mcp with your API key — see Connect a remote AI client.

Then ask your assistant List my DBConvert connections. — if the connections you see in Data Explorer come back, you're done.

→ Full step-by-step, screenshots, and Docker setup: Setup.

No connections yet? An empty list back means MCP is wired up correctly — there's just nothing to show. Add one in the Data Explorer sidebar (+ New Connection) and ask again; see Connection management.

What you can ask your AI assistant

Real prompts, real answers — every exchange below came back from a live workspace, numbers and all:

Database inspection

You: Describe the orders table on my Postgres demo connection — columns, keys, indexes. Lay it out as a table.

AI: public.orders — 10 columns, primary key order_id:

Column	Type	Null	Notes
order_id	bigint	no	primary key
customer_name	text	no
customer_email	text	yes
order_date	timestamp	no	indexed
status	text	no	indexed
amount	numeric(10,2)	yes
currency	char(3)	no	default 'USD'
region	text	no
items	integer	no
updated_at	timestamp	no	default now()

No index on region — add one if you group orders by region.

Analytics

A light analytical question returns real numbers, not a guess — the AI writes the multi-table join, runs it read-only, and hands back the rows:

You: What are my top film categories by rental revenue? (sakila sample)

AI:

Category	Revenue
Sports	$5,314.21
Sci-Fi	$4,756.98
Animation	$4,656.30
Drama	$4,587.39
Comedy	$4,383.58

Joined category → film_category → film → inventory → rental → payment, ran in ~55 ms. Want the query to reuse, or the full top 15?

Federated query across sources

A federated SELECT joins data that lives in different systems — no ETL, no staging table. The everyday case: your transactional table sits in one database, but the reference data you need to group by lives in another.

You: Roll up revenue from my live Postgres orders by sales manager. The region → manager mapping lives in my MySQL reference DB, not in the orders table.

AI: Joined orders (Postgres) to territories (MySQL) on region in a single federated query — neither table left its database:

Manager	Regions	Revenue
Dana Ruiz	US-West, US-East	$1,679,420.18
Lena Fischer	EU-Central, EU-West	$1,284,905.77
Arun Mehta	APAC, MEA	$1,251,330.42
Marco Silva	LATAM	$864,508.96

That's the full $5,080,165.33 across 5,000 orders, attributed by territory — a grouping neither database could produce on its own.

(The orders total and region names here are live; the territories mapping is illustrative.)

Query review

You: EXPLAIN this and tell me whether an index would help: SELECT * FROM orders WHERE region = 'EU-Central' AND status = 'pending'

AI: The planner already uses idx_orders_status — a bitmap index scan pulls the pending rows, then it filters region on the heap (estimated cost 89.62, ~86 rows out). region isn't indexed on its own. A composite index on (status, region) would push the region filter into the index instead of rechecking ~503 pending rows — a modest win at 5,000 rows, more worth it if this query runs hot or the table grows. Here's the CREATE INDEX; you run it.

Stream troubleshooting

You: My MySQL → PostgreSQL CDC stream stopped overnight. List my streams, check status and recent errors, and tell me what to fix.

AI: Found it — get_stream_status shows the latest run of 10M-cdc-mysql2pg FAILED with Error 1049 (42000): Unknown database 'target', flagged source-side ("Source run failed"). The CDC source is pointed at a database target that doesn't exist on the MySQL server. Fix: create it (or correct the database name on the connection), then restart. (get_stream_recent_errors came back empty — the failure lived in the run history, so that's where I looked.)

Cross-source validation

You: Is my Parquet export of orders still in sync with the live Postgres table?

AI: Joined the live table and the Parquet file in one cross-source query, matched on order_id: both hold 5,000 rows, with 0 present only in Postgres and 0 only in Parquet — no rows added or removed since the export. The snapshot is still current.

What it cannot do

The MCP server is read-only — it inspects and advises, it never writes:

• No data or schema changes — no INSERT / UPDATE / DELETE, no DROP / ALTER / CREATE. Only SELECT and WITH ... SELECT pass the safety filter; everything else is rejected at the server before it reaches your database.
• No connection or credential changes — connections are read from your workspace, never edited.
• No stream control in this version — the AI can't start, stop, pause, resume, or reset streams yet. It surfaces status, errors, and the fix; you run the action. (Controlled write actions may arrive later, behind explicit safeguards.)

When the AI suggests a change, you (or DBConvert Streams via the UI) run it. The AI never touches the trigger. See Safety & privacy for the full boundary.

How it works

On the desktop app, the MCP server runs as a small process alongside DBConvert Streams; your AI client (Claude Code, Cursor, etc.) starts it on demand and talks to it over standard input/output (stdio). On a Docker or server deployment it runs as a service in your own stack and your client reaches it over HTTP. Either way it runs on your infrastructure and only ever responds to your client's read-only requests — it never calls out to DBConvert or your AI provider on its own.

⚡ Always live, never snapshotted. Edit a connection in the DBConvert Streams UI and the MCP server picks up the change in a fraction of a second — no restart of your AI assistant required. The AI always reads current state, so it never advises you from a stale schema or a connection you already changed.

For the full, plain-language list of everything the AI can reach, see the MCP tools reference.

See full sessions

The exchanges above are trimmed. For complete transcripts — plain-English SQL on the sakila sample and a federated Postgres + Parquet diff, both on the cheap-and-fast Claude Haiku 4.5 (no Opus needed).

The pattern throughout: the AI does the writing and the read-only verification; you decide what actually runs against your data — a fast analyst on tap, not an autopilot for your production database.

In this section

• Setup — wire the MCP server into Cursor, VS Code with GitHub Copilot, Windsurf, Claude Code, Claude Desktop, Gemini CLI, or Codex CLI.
• Tools reference — the 26 read-only tools, in plain language.
• Safety & privacy — what the AI can and cannot do, what it sees, and how secrets are redacted.
• Examples — real end-to-end sessions: plain-English SQL and federated validation.
• Troubleshooting — fixes for common setup and runtime issues.