Grounding an assistant

An assistant writing SQL against your warehouse has two ways to decide what status means. It can infer from the column name and the rows it can see, or it can look the definition up. Only one of those is repeatable.

The failure this fixes

Ask a coding assistant to write a query filtering on order status and it will produce something plausible: WHERE status IN ('shipped', 'completed'). Plausible is the problem. If your estate also uses return_pending, the query is quietly wrong, it passes review because it reads correctly, and nothing in your pipeline objects.

The model is not being careless. Nothing in the schema it was given carries the allowed values, so it filled the gap with the most likely guess. Give it somewhere to look and the guess disappears.

The pattern

1. Model the meaning once. Bring the schema your stack already produces, then fix the definitions in one place — the allowed values, the owner, what the field is actually for.
2. Attach the MCP server so the assistant can read that model at the moment it writes code. See MCP server.
3. Tell the assistant to consult it before asserting. The instruction that does the work is plain: look up before you make up. Put it in your project rules, your system prompt, or your agent's standing instructions.
4. Make lookups cheap. Point the assistant at the specific model for the repository it is working in, not at everything. A narrow, correct source beats a broad one it will not read.

A rule you can paste

Before you assert what a field means, allows, or is used for, look it up in CoreModels
via the MCP server. If the model has no definition for it, say so — do not infer one
from the column name.

That last clause matters more than the first. An assistant that reports a gap gives you something to fix; one that infers gives you a bug shaped like an answer.

Where to go next

Every connector documents its own MCP path — how to expose that estate's model to an agent. The dbt one is the fullest worked example: dbt → MCP.