How to organize your data so an AI picks the right tables

What the model actually sees

Over MCP, a model connected to a governed data gateway has exactly four moves: list the sources, list a source's tables, describe a table's columns, and run a read-only query. That's the whole picture. It behaves like a sharp analyst dropped into your company on day one with only a list of table and column names and a read-only SQL prompt: it reads the names, forms a hypothesis, peeks at a few rows, writes a query.

The names and the shape of your data are the entire signal. No hidden hints, no business glossary travelling over the wire. If a human analyst could pick the right table from the names alone, so can the model. If they'd have to guess — so will it.

Everything below follows from that one fact.

Why it picks the wrong dataset

1. Cryptic names. A source called db1 with tables t_fct_0042 and dim_x tells the model nothing. It will guess, and guess wrong.
2. Ambiguity. If sales, sales_old, sales_v2 and sales_export all exist, it can't know which is canonical — it often picks the first or the largest.
3. Raw tables with no curated summary. Asked for "total revenue last quarter" against a 20-million-row line-item table, the model can write the aggregation — but it must infer the grain, the date column, the revenue column, and the filters. Each inference is a chance to be wrong.
4. Inconsistent vocabulary. People ask about "customers"; the table is accts. Every gap lowers the odds.
5. Too much exposed at once. A business link that can see 400 tables across 12 schemas makes the model wade through noise. Fewer, well-chosen tables — sharper answers.

The seven things that make it reliable

1. Name sources, tables, and columns in business language

Use the words your people use when they ask questions. revenue, not amt_n. orders, not t_ord. The name is the documentation.

2. Build curated rollup views for the questions people actually ask

The single highest-leverage step. For every recurring business question, create a view that already answers it, named after the question. The model will strongly prefer a revenue_by_region_monthly view over re-deriving from raw rows — and it gets the numbers right because you encoded the grain and the math once. In the production fleet deployment we run, a single source carries an 18-million-row sales table plus ~30 rollup views; natural-language questions land on the views, the raw table stays available for the rare deep dive.

3. One concept, one canonical table

Don't leave sales, sales_old and sales_v2 side by side in an exposed source. Ambiguity is the enemy; a single obvious choice is the goal.

4. One grain per table, obvious from the name

A table should answer "what is one row?" from its name: orders = one order; revenue_by_region_monthly = one region-month. Mixed grains lead to double-counting.

5. Consistent, predictable vocabulary

One term per concept, everywhere. If it's customer_id in one table, don't call it client_ref in the next — consistent keys let the model join without guessing.

6. Share only the right sources with business users

Scope deliberately: the curated, rollup-heavy source goes into the business scope; messy raw and staging sources stay behind the engineers-only door. The smaller and cleaner the set a business link exposes, the better the answers.

7. Manufacture clean datasets on a schedule

When the view you want spans sources or is expensive to compute live, build it as a scheduled dataset: pull, transform read-only, publish under a friendly name, refresh automatically. The result is a small, purpose-built dataset the model picks with confidence.

A quick before/after

Before — one source prod, 312 tables including f_txn, f_txn_arch, stg_txn, columns like amt, cur, cdt. "Revenue by region last quarter?" means finding the right transaction table among three, guessing that amt×cur is revenue, guessing cdt is the date. Coin-flip territory.

After — a business-scoped source exposing revenue_by_region_quarterly (region, quarter, total_revenue, order_count). The model sees a view named almost exactly like the question and writes one correct SELECT. Right answer, first try.

Checklist

• Source, table, and column names read like business language.
• A curated view exists for each recurring question, named after the question.
• Exactly one canonical table per concept — no _old/_v2 clutter exposed.
• Each table has one clear grain, evident from its name.
• Consistent terms and join keys across tables.
• Only curated sources are shared with business; raw stays engineers-only.
• Scheduled datasets keep cross-source or expensive views fresh.

Do these and natural-language questions stop being a gamble: the model reads names that match how people ask, lands on a view that already holds the answer, and returns numbers you can trust.