How it works

From question to answerin about ten minutes.

Bring your data one of three ways — send it to us, connect your storage, or connect your warehouse or database — add one URL to Claude or ChatGPT, and ask in plain English. No dashboards to build, no SQL to learn, and everything the AI can do is read-only.

Start free — 30 queries, no card
Walk the 3 steps

No credit card · Read-only access · ~10-minute setup · Credits never expire

Read-only by constructionEncrypted credentials, TLS on by defaultEvery question logged

Live, not screenshots

Everything is alive.

Four mechanisms from the product, running right on this page.

Table-level exposure in DataAssist-IO: you choose exactly what the AI sees An admin's table list in DataAssist-IO on the left shows four org tables — customers, orders, invoices and payroll — each with an exposure toggle. One by one the toggles for customers, orders and invoices slide on and fill green, and as each one flips, the matching table chip pops in on the right-hand panel labelled what your AI can see. The payroll toggle stays off and payroll never appears on the AI side — its slot on the right stays a dashed outline marked not exposed. Between the two panels sit the DataAssist-IO mark and an MCP badge. A note below reads: unexposed tables do not exist to the AI. DataAssist-IO MCP only what you expose your tables — you choose customers orders invoices payroll what your ai can see customers orders invoices payroll — not exposed Claude · ChatGPT · any MCP client unexposed tables don't exist to the AI
You choose exactly what the AI sees.
DataAssist-IO query guardrails: runaway questions are stopped at the source Three queries travel toward a database labelled Your data on the right, each crossing a DataAssist-IO guard line in the middle. A normal SELECT with a small fast-timer chip passes the guard, earns a green check, and answers in seconds. A heavy query runs long — its clock face fills up — and is turned back at the guard by a statement timeout, set in the engine's own dialect; it never reaches the data. A third query's scan meter climbs to a cost ceiling and is rejected before it spends; it bounces back too. The data on the right stays untouched by the two runaway queries. DataAssist-IO query guardrails answer in seconds SELECT … fast SELECT … heavy statement timeout set in your engine’s own dialect ceiling SELECT … full scan per-query cost ceiling rejected before it spends Your data untouched by runaways only sane queries land
Runaway queries stopped at the source.
Every question asked through DataAssist-IO is logged automatically A teammate asks a question from an AI chat tool on the left. The question passes through DataAssist-IO in the centre, and a new entry slides into the Tool Calls log on the right — recording who asked, what, when, and a green check for success. New rows keep arriving as more questions are asked, and org admins can review them all. question logged automatically ? Your team asks via Claude · ChatGPT DataAssist-IO records every question Tool Calls who · what · when
Every question logged — who, what, when.
Your AI discovers your tables automatically through DataAssist-IO A generic AI-client panel that works with Claude, ChatGPT and any MCP client. First a DataAssist-IO tool chip runs list_tables and three table cards appear: customers, orders and invoices. Then a describe_table chip pulses on the orders card, which expands to show a plain-English description — one row per order, refreshed daily — and four column chips with type tags: order_id number, customer text, amount number, placed_at date. Finally a green check appears with the line ready to answer questions. Your AI assistant — works with Claude, ChatGPT & any MCP client DataAssist-IO list_tables · read-only describe_table · orders customers table orders table “One row per order, refreshed daily” order_id · number customer · text amount · number placed_at · date invoices table ready to answer questions — tables and columns understood
The AI discovers your tables itself.

The ten-minute path

Three steps between you and your first answer

Here’s the whole thing at a glance.

Set up DataAssist-IO in three steps A three-step setup strip. Step one: connect your data — it arrives one of three ways: send it to us, connect your storage, or connect your warehouse or database. Step two: add DataAssist-IO to Claude, ChatGPT, or any MCP client. Step three: ask questions in plain English and get read-only answers. A progress line fills from left to right, lighting each step with a checkmark before the loop gently resets. 1 Connect your data arrives one of three ways 2 Add to Claude or ChatGPT or any MCP client 3 Ask in plain English read-only answers, in seconds DataAssist-IO
Typically under ten minutes. No engineers needed.

Prefer every click spelled out? Read the setup guide → — both clients, screenshots included.

What teams actually ask

Pick your team — these are real, answerable prompts

Every question below runs directly against your connected tables — no SQL, no export, no waiting on anyone. Nothing here is a promise about results; it’s just what asking looks like.

Connect the database behind your CRM or orders system — or just upload the export you already pull every Monday — and ask:

“Top 10 accounts by pipeline value this quarter?” “Which deals have been stuck in the same stage for over 30 days?” “Which customers went quiet in the last 90 days?” “New accounts added this month, broken down by region?”

Connect your billing or accounting database — or upload the month-end extracts — and ask:

“MRR by month for the last six months?” “Which invoices are overdue right now, and by how many days?” “Spend by vendor this quarter compared to last?” “Which customers changed plans last month?”

Connect your helpdesk's database or its reporting export, and ask:

“Which tickets breached SLA last week?” “Ticket volume by category this month?” “Which accounts opened the most tickets this quarter?” “Average first-response time, by weekday?”

Connect your inventory or order-management database — or the warehouse exports you already pull — and ask:

“Which orders are pending shipment right now?” “Which items are below their reorder level?” “Deliveries delayed more than three days, by carrier?” “Stock on hand by warehouse for our top 20 SKUs?”

Three ways in, one contract

Three ways your data arrives, one way it behaves: governed, read-only, analytics-ready

Arrive → analytics-ready → ask. However your data gets here, it comes out the same: encrypted, refreshed on your schedule, governed table by table, audited question by question — and answerable in plain English.

Send us your data

file uploads · scheduled file drops · private landing area

Stored encrypted in your organization's isolated workspace.

Upload files, schedule pulls from your file server, or push to a private landing area in your cloud storage. Files are parsed and typed once at ingestion — schema inferred automatically — and stored as columnar, analytics-ready tables in an open table format: encrypted, versioned on every refresh, isolated from every other organization. Delete a table and its stored data goes with it.

Connect your storage

your cloud object storage & table catalogs

Read in place — never copied, read-only.

Point us at your own object storage or catalog and your files stay in your account. We read exactly what you point us at — nothing more — so ownership, retention, and residency stay entirely yours.

Connect your warehouse or database

your warehouse or operational database

Read in place — never copied, read-only.

A direct, read-only connection with a login you control. Each question is pushed down to your engine as a validated, SELECT-only statement and only result rows travel back, so answers reflect the data as it is right now — no sync lag, no second copy to secure.

Whichever way it arrives: you choose exactly which tables are exposed, connection credentials are encrypted at rest, and everything the AI can do is read-only. Full security overview →

See all three ways in detail → — uploads, storage, and warehouse connections.

Built for teams

One connection, the whole team answered

An admin sets it up once; everyone else just signs in and asks. Access, spend, and oversight are org-level from day one.

Teams and team-scoped table access in DataAssist-IO An admin in DataAssist-IO grants tables to two teams — table-level exposure controls with team-scoped access grants. The Sales team is granted the orders and customers tables; the Finance team is granted the invoices and payroll tables. Animated query dots travel from each team to its granted tables and arrive with a soft pop. One Sales query heads toward the payroll table but stops at a shield marked not granted — a viewer can only reach the tables their team was granted. DataAssist-IO admin granted granted not granted teams Sales team orders · customers Finance team invoices · payroll tables orders customers invoices payroll
Group viewers into teams and grant each team exactly the tables it should see — a viewer only reaches what their team was granted.

Roles that match reality

Admins manage sources, users, and billing. Viewers just connect their AI and ask questions — they never touch configuration.

Team-scoped tables

Group viewers into teams and grant each team exactly the tables it should see — nothing more. Sales asks about pipeline; they never see payroll.

One shared balance

Credits are pooled across the org — no per-seat fees, so adding a teammate costs nothing. One question, one credit, whoever asks.

Tool Calls: the audit trail

Every question lands in the Tool Calls log — who asked, what ran, when, and whether it succeeded — visible to your admins in the app.

Under the hood

For the person who asks “but how, exactly?”

Optional reading — the page above is the whole story. This is the engineering behind it, in plain terms.

What is MCP, and why does it matter?

MCP — the Model Context Protocol — is an open standard that lets AI assistants use external tools instead of guessing. Rather than pasting exports into a chat window, your assistant asks a tool for exactly the data it needs. DataAssist-IO is an MCP server: it publishes a small set of read-only tools — list your tables, describe their columns, run a validated query, fetch a sample — behind the single URL you added in step 2.

Because it's an open standard, one connection works everywhere the standard does: Claude, ChatGPT, and any MCP-compatible client. When you ask a question, the assistant discovers your tables, writes a query, and sends it to DataAssist-IO — which validates it and runs it read-only: for live connections the question is pushed down to your engine and only result rows travel back. Sign-in is OAuth, so every request is tied to a real user in your organization and shows up in the Tool Calls log.

How do you guarantee queries are read-only?

In layers. Every SQL statement is parsed and validated before it runs — only single, read-only SELECT statements pass; writes, schema changes, and multi-statement tricks are rejected before they ever reach your data. On the major relational engines there's a second, independent layer: the database session itself is opened read-only, so even a statement that somehow slipped past validation would be refused by your database. Document databases are queried with read-only aggregation pipelines — every write stage is denied. And since you connect with a read-only login you control, your own database remains the final gate.

What stops a runaway query?

Every engine runs with a server-side statement timeout, issued in each engine's own dialect. A pathologically heavy question is cut off at the source instead of sitting on your database, and the assistant simply gets an error message it can react to.

What about cloud-warehouse query costs?

Cloud warehouses that bill by data scanned run every query under a per-query cost ceiling — an over-budget scan is rejected before it spends anything. Engines with a result cache serve repeated identical questions instantly, and for free. Engine-by-engine details live on the integrations page.

DataAssist-IO query guardrails: runaway questions are stopped at the source Three queries travel toward a database labelled Your data on the right, each crossing a DataAssist-IO guard line in the middle. A normal SELECT with a small fast-timer chip passes the guard, earns a green check, and answers in seconds. A heavy query runs long — its clock face fills up — and is turned back at the guard by a statement timeout, set in the engine's own dialect; it never reaches the data. A third query's scan meter climbs to a cost ceiling and is rejected before it spends; it bounces back too. The data on the right stays untouched by the two runaway queries. DataAssist-IO query guardrails answer in seconds SELECT … fast SELECT … heavy statement timeout set in your engine’s own dialect ceiling SELECT … full scan per-query cost ceiling rejected before it spends Your data untouched by runaways only sane queries land
Heavy questions are cut off at the source — your database never carries a runaway query.
DataAssist-IO

Ten minutes from now, this could just be how you work.

Connect a source, add one URL to Claude or ChatGPT, and ask your first question.

Start free — 30 queries, no card

30 free questions · no credit card · read-only access · ~10-minute setup

Read the setup guide  ·  Security overview