dbconvert-streams
This MCP server provides read-only visibility into DBConvert Streams connections and data sources.
dbconvert_list_data_sources— list configured connections/data sources with id, name, type, and optional cloud provider; supports a limit (default 100, max 500) and reports truncation.dbconvert_get_connection— get credential-free details for a single connection, including host, port, username, default database, SSL/SSH topology, cloud provider, and source-specific settings (database, files, S3, GCS, Azure, Snowflake).All operations are strictly read-only; passwords, SSH private keys, and cloud access keys/tokens are structurally absent and cannot be retrieved.
Enables browsing S3 buckets and objects, inspecting file schemas, previewing files, and querying S3 storage alongside other data sources.
Allows connecting to MySQL databases to inspect schemas, tables, and views, and to run read-only SQL and federated queries across sources.
Allows connecting to PostgreSQL databases to inspect schemas, tables, and views, and to run read-only SQL and federated queries across sources.
DBConvert Streams
Database IDE + migration + real-time CDC — in one workflow.
Query data, move it, keep it in sync, and let your AI assistant see it all
without switching between tools.
If this looks useful, consider giving it a ⭐
Why this exists
Most setups look like this:
a DB client for queries
scripts or tools for migration
a separate CDC pipeline
It works, but it's fragmented.
DBConvert Streams combines these into one workspace.
What it feels like
Think of it as:
DBeaver / DataGrip
migration tool
CDC
but without switching tools every time
Example
Run queries across databases and files:
SELECT *
FROM read_parquet('orders.parquet') o
JOIN postgres.public.customers c
ON o.customer_id = c.id
LIMIT 10;Then use the same query as a data source — and stream it anywhere.
What you can do
explore databases, files, and S3
run SQL across multiple sources
move data between systems
keep it in sync with CDC
connect Claude, Cursor, or Copilot — the AI reads your live schemas, data, and streams (read-only, via MCP)
All in the same workflow.
Note: This is the public home of DBConvert Streams — example configurations, documentation, issue tracking, and release notes. The product itself is proprietary.
Quick Start
Runs anywhere — your laptop, a VPS, or your own infra. No cloud dependency, no vendor lock-in.
Desktop App
Download for Windows, macOS, or Linux — no account required.
AI client extension
Grab dbconvert-streams-<version>.mcpb from Releases and drop it into Claude → Settings → Extensions. It asks for connection strings and folders, and nothing else has to be installed — no DBConvert Streams, no toolchain, no server to run.
postgres://user:password@host:5432/dbname
mysql://user:password@host:3306/dbname
s3://bucket/folder?region=us-east-1Several sources go in the one field, separated by spaces — shop=postgres://… orders=mysql://… — and a single question can join across all of them.
Add folders of Parquet, CSV or JSON files with the folder picker. Every source becomes read-only tools in your chat, and one question can span several of them at once.
One file covers Windows and Linux — the bundle carries a binary for each and picks the right one. macOS is planned for a later release.
Not a Claude user? The same server runs as a container, and every MCP client that can launch one can use it:
docker run -i --rm slotix/stream-mcp "shop=postgres://user:password@host:5432/shop"Cursor and VS Code can set that up in one click — Add to Cursor · Add to VS Code — VS Code asks for the connection string as you install it; in Cursor you replace the sample one. Folders, S3 keys and the rest: standalone server.
The bundled server is proprietary software, distributed under the DBConvert Streams licence. The MIT licence in this repository covers the examples, docs and assets here, not that binary.
Self-Hosted (Docker)
Deploy on any machine with Docker — a local server, a VPS (DigitalOcean, Hetzner, AWS EC2, etc.), or your own infrastructure:
curl -fsSL https://dbconvert.nyc3.digitaloceanspaces.com/downloads/streams/latest/docker-install.sh | shRelated MCP server: sqlite-mcp
What is DBConvert Streams?
DBConvert Streams is a database IDE with built-in migration and real-time CDC.
Browse databases, local files, and S3 storage. Edit data directly. Run federated SQL queries that join tables across different database engines — no intermediate exports needed.
Key Features
In practice, it comes down to this:
Database IDE & Workspace (Free)
Data Explorer — Browse databases, files, and S3 in one place
ER Diagrams — Visualize database relationships
Schema Comparison — Compare schemas and data across databases
Schema Navigation — Persistent state and search across connections
Federated SQL
Execute SQL queries across multiple databases and file sources simultaneously
Join live PostgreSQL and MySQL tables using connection aliases
Query CSV, JSON, Parquet files and S3 storage alongside databases
Built-in AI Chat — new in 2.5.0
Ask about the database work already open in the desktop app: a table, view, file, SQL console, connection, or migration/CDC stream. AI Chat starts with that live workspace context, so it can inspect schemas and data, explain or repair a failed query, and diagnose stream status without asking you to paste DDL into a separate chat.
Use your own installed agent CLI — Claude Code, Codex, GitHub Copilot CLI, or OpenCode. AI Chat automatically supplies the relevant scoped subset of DBConvert's read-only tools and shows tool activity while it works; it cannot change connections, configuration, streams, or data.
AI Assistants via MCP — new in 2.4
Built-in MCP server: Claude, Cursor, VS Code Copilot, Windsurf, Gemini CLI, and Codex read live schemas, data, and stream state — no more pasting DDL into chat
27 read-only tools: inspect workspace connections, schemas, tables and views; run read-only SQL and federated queries; compare schemas and samples; diagnose streams; browse files and S3
One-click setup from the ✨ AI Assistants panel; Docker deployments expose
/mcpover HTTP(S)Read-only by design: only
SELECTpasses the server-side filter — the AI can look and advise, never write
Tools
DBConvert Streams exposes these 27 read-only MCP tools. The names below match the live MCP server.
Connections and schema
dbconvert_list_connections— list workspace connectionsdbconvert_get_connection— inspect one connectiondbconvert_list_databases— list databasesdbconvert_list_schemas— list schemasdbconvert_list_tables— list tablesdbconvert_list_views— list views
Table and view inspection
dbconvert_describe_table— inspect table columns and keysdbconvert_preview_table— preview table rowsdbconvert_describe_view— inspect a viewdbconvert_preview_view— preview view rows
Read-only SQL
dbconvert_run_select— run a SELECT querydbconvert_explain_select— explain a SELECT query
Schema and data comparison
dbconvert_compare_schemas— compare schemasdbconvert_compare_data_sample— compare data samples
Stream diagnostics
dbconvert_list_streams— list streamsdbconvert_get_stream— inspect a streamdbconvert_get_stream_status— get stream statusdbconvert_get_stream_stats— get stream throughput and statisticsdbconvert_get_stream_recent_errors— inspect recent stream errorsdbconvert_get_stream_recent_logs— inspect recent stream logs
Files and S3
dbconvert_list_files— list workspace filesdbconvert_get_file_schema— inspect a file schemadbconvert_preview_file— preview file rowsdbconvert_list_s3_buckets— list S3 bucketsdbconvert_list_s3_objects— list S3 objects
Federated SQL
dbconvert_run_federated_select— run a read-only query across sourcesdbconvert_explain_federated_select— explain a federated SELECT query
Only read-only operations are exposed: the server-side filter permits
SELECT, so an AI client cannot alter connections, configuration, streams, or
data. For client setup, see the MCP setup guide.
Data Migration (Load Mode)
Rapidly move large datasets between databases with automatic schema conversion and validation.
Performance: 23 million rows (4.38 GB) migrated from MySQL to Parquet in 35.7 seconds at 136 MB/s.
Real-time CDC (Change Data Capture)
Stream INSERT, UPDATE, and DELETE operations from source to target in real-time with minimal latency. Supports CDC to databases, files, and S3 storage.
When this is probably not for you
you need 100+ connectors (SaaS, APIs, etc.)
you already run Kafka pipelines at scale
you need complex ETL / transformations
Screenshots
Data Explorer
Browse schemas, view and edit data across multiple database connections with a unified tree navigation:

Federated SQL
Join tables across MySQL, PostgreSQL, and file sources (CSV, Parquet) in a single query:

ER Diagrams
Visualize database relationships with interactive entity-relationship diagrams:

Stream Configuration
Configure data migration and CDC streams with table selection, custom queries, and transfer settings:

Stream Monitoring
Track data streams with real-time metrics — rows, data size, transfer rates, and per-table progress:

AI Assistants
Connect your AI client with one click — it reads the same workspace you see, read-only:

Supported Sources & Targets
Sources
MySQL / MariaDB / Percona
PostgreSQL / CockroachDB
Amazon RDS, Aurora, Google Cloud SQL, Azure Database
Local files (CSV, JSONL, Parquet)
S3-compatible storage (AWS S3, MinIO, DigitalOcean Spaces, Wasabi)
Targets
MySQL / PostgreSQL
Snowflake
CSV / JSONL / Parquet (local files)
Amazon S3 / MinIO / S3-compatible storage
Google Cloud Storage (GCS)
Azure Blob Storage
Deployment Options
Run it anywhere — no cloud account required, no vendor lock-in.
Method | Description |
Desktop | Windows, macOS, Linux — local setup, no account required |
Self-hosted | Docker / Docker Compose on any machine — local server, VPS, or your own infra |
Pricing
The Database IDE is free forever. For data migration and CDC streaming, see pricing details.
Examples
Most people never touch the API. The UI covers connections, table selection, federated SQL, stream configuration, and monitoring end-to-end. The
curlexamples below are for users who want to script deployments, wire DBConvert Streams into CI/CD, or drive it from another service — not a required workflow.
Connections are managed separately and stream configs reference them by ID. Here are typical workflows via the API.
1. Create connections
# Create a MySQL source connection
curl -X POST http://localhost:8020/api/v1/connections \
-H "Content-Type: application/json" \
-d '{
"name": "mysql-source",
"type": "mysql",
"host": "localhost",
"port": 3306,
"username": "root",
"password": "password"
}'
# Create a PostgreSQL target connection
curl -X POST http://localhost:8020/api/v1/connections \
-H "Content-Type: application/json" \
-d '{
"name": "pg-target",
"type": "postgresql",
"host": "localhost",
"port": 5432,
"username": "postgres",
"password": "password"
}'2. MySQL → PostgreSQL (load)
One-time migration with table selection:
{
"name": "mysql-to-postgres-migration",
"mode": "load",
"source": {
"connections": [{
"connectionId": "<mysql-connection-id>",
"database": "sakila",
"tables": [
{ "name": "actor" },
{ "name": "film" },
{ "name": "customer" }
]
}]
},
"target": {
"id": "<pg-connection-id>",
"spec": {
"db": {
"database": "target_db",
"schema": "public",
"schemaPolicy": "drop_and_recreate"
}
}
}
}3. MySQL → PostgreSQL (CDC)
Real-time replication capturing inserts, updates, and deletes:
{
"name": "mysql-to-postgres-cdc",
"mode": "cdc",
"source": {
"connections": [{
"connectionId": "<mysql-connection-id>",
"database": "sakila",
"tables": [
{ "name": "actor" },
{ "name": "film" }
]
}],
"options": {
"operations": ["insert", "update", "delete"]
}
},
"target": {
"id": "<pg-connection-id>",
"spec": {
"db": {
"database": "target_db",
"writeMode": "upsert"
}
}
}
}4. PostgreSQL → S3 Parquet (load)
Export database tables to Parquet files on S3:
{
"name": "pg-to-s3-parquet",
"mode": "load",
"source": {
"connections": [{
"connectionId": "<pg-connection-id>",
"database": "analytics",
"tables": [
{ "name": "orders" },
{ "name": "customers" }
]
}]
},
"target": {
"id": "<s3-connection-id>",
"spec": {
"s3": {
"fileFormat": "parquet",
"upload": {
"bucket": "my-data-lake",
"prefix": "exports/"
}
}
}
}
}5. Multi-source federated query (load)
Join data from MySQL and PostgreSQL into one target:
{
"name": "federated-migration",
"mode": "load",
"source": {
"connections": [
{
"alias": "my1",
"connectionId": "<mysql-connection-id>",
"database": "sakila"
},
{
"alias": "pg1",
"connectionId": "<pg-connection-id>",
"database": "dvdrental"
}
]
},
"target": {
"id": "<target-connection-id>",
"spec": {
"db": { "database": "warehouse" }
}
}
}6. Start a stream
curl -X POST http://localhost:8020/api/v1/stream-configs/<config-id>/start7. Monitor progress
curl http://localhost:8020/api/v1/streams/<stream-id>/statsSee the full API documentation for all endpoints and options. Standalone stream-config files live in
examples/api/, and reproducible benchmarks (including a side-by-side vs Debezium) are inexamples/benchmarks/.
Learn More
Feedback and Support
Have questions or feedback? Use Discussions or open an Issue.
Available Tools
2 toolsdbconvert_get_connectionARead-only
Get credential-free details for one connection: host, port, username, default database, SSL/SSH topology, cloud provider. Passwords, SSH private keys, and cloud access keys/tokens are never included — they are structurally absent, not redacted, so there is no way to retrieve them through MCP. Report only the fields present in the response.
| Name | Required | Description | Default |
|---|---|---|---|
| connectionId | Yes | Stored DBConvert connection ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| ssh | No | |
| ssl | No | |
| name | Yes | |
| spec | No | |
| type | Yes | |
| created | Yes | |
| cloudProvider | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the safe-read annotations, the description provides critical behavioral context: credentials are structurally absent, not redacted, and impossible to retrieve through MCP. It also warns the agent to report only fields present in the response, which aligns with the openWorldHint annotation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with zero fluff. The core purpose is front-loaded, and the security caveat is concisely stated without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with an output schema, safe-read annotations, and a single documented parameter, the description is nearly complete. The only minor gap is that it does not point the agent to the sibling list tool as a source for obtaining a connectionId.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter connectionId is already described in the schema as 'Stored DBConvert connection ID'. The description adds no new parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), names the resource ('one connection'), and enumerates exactly what fields are returned. It also implicitly distinguishes itself from the sibling list tool by focusing on a single connection rather than listing data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this tool targets one specific connection, which implies when to use it versus listing tools. However, it does not explicitly mention the sibling dbconvert_list_data_sources or state when not to use this tool, leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dbconvert_list_data_sourcesARead-only
List DBConvert Streams connections. Each item has exactly id, name, type, and (optionally) cloudProvider — nothing else. For host/port/username and other connection details use get_connection. Passwords and cloud keys are never exposed by any tool. Report connections using only the fields present; do not add invented fields like used_for or row_counts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum items to return, default 100, max 500 |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| truncated | Yes | |
| limitApplied | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a read-only, non-destructive operation. The description adds meaningful behavioral context beyond these annotations: each item has exactly four fields, secrets are never exposed, and the agent must not fabricate fields. This is useful guidance for correctly interpreting tool output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. Purpose is front-loaded, sibling routing follows, and the anti-fabrication instruction is precise. Every sentence contributes to correct tool usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with one optional parameter and an existing output schema, the description covers the purpose, exact return shape, sibling distinction, and security caveat. Nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, limit, is fully documented in the input schema with default and maximum values, so schema coverage is 100%. The description does not add parameter-level detail, but none is needed because the schema already carries the full meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List DBConvert Streams connections.' It goes further than the tool name by enumerating the exact item fields and explicitly distinguishing this tool from dbconvert_get_connection. An agent can immediately tell what type of operation this is and what it returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes the agent to the sibling tool: 'For host/port/username and other connection details use get_connection.' It also clarifies that passwords and cloud keys are never exposed by any tool, setting correct expectations about what not to attempt here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
The two tools have complementary, non-overlapping roles: one lists connection summaries with basic metadata, and the other fetches detailed connection information. The descriptions explicitly cross-reference each other, so an agent should not confuse them.
Both tools follow the same dbconvert_<verb>_<noun> snake_case pattern (get_connection, list_data_sources), making the action and resource predictable and consistent.
Two tools is below the typical well-scoped range; while they cover a narrow read-only lookup use case cleanly, the surface feels thin for a product named DBConvert Streams and offers no operations beyond listing and inspecting connections.
The read-only connection metadata workflow (list then get detail) is covered, but the tool set omits connection lifecycle operations and any stream-related tools, so agents with broader management tasks will hit dead ends.
Maintenance
Related MCP Connectors
Query 40 databases from Claude, ChatGPT, or Cursor — on any device. Read-only, encrypted, audited.
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Related MCP Servers
- AlicenseAqualityCmaintenanceQuery SQL databases (SQLite, PostgreSQL, BigQuery, Databricks) in natural language through a business semantic layer — glossary, metrics, and a data dictionary grounded against your real schema. Read-only by default, with an embedded SQLite + sqlite-vec metadata store and no external infra required.252MIT
- AlicenseNot gradedqualityCmaintenanceRead-only SQLite access for AI agents in a single ~1 MB static binary. Query tool with row limits, list_tables, and table schemas exposed as MCP resources. The database is opened read-only, so writes fail at the SQLite layer. No Python, no Node, no runtime to install; SQLite is compiled in. Binaries for Linux, macOS, and Windows.MIT
- FlicenseNot gradedqualityFmaintenanceProvides read-only SQL query access to Postgres and DuckDB databases via MCP tools, with extensive security hardening for public endpoints.1
- AlicenseAqualityAmaintenanceRead-only, PII-masked MCP server for querying data federated through DuckDB — list sources/tables, inspect schemas, and run SQL across Postgres, MySQL, SQLite, Snowflake, BigQuery, Excel, and files, governed per source/table/column by a charter.yaml contract. Snowflake, BigQuery, Excel, and files, governed per source/table/column by a charter.yaml contract.612Apache 2.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/slotix/dbconvert-streams-public'
If you have feedback or need assistance with the MCP directory API, please join our Discord server