Onboard your coding agent to data warehouse

It's 2:07 a.m. Finance's nightly export has just failed. The column it filters on was renamed at 4 p.m., in a pull request your coding agent wrote. The tests passed. The review passed. Nobody on your team knew Finance read that column.

Your agent isn't careless. It's a brilliant new hire who has never met anyone at the company. It reads your repo in seconds, but the repo doesn't say who else uses your tables, what already exists, or what a query costs when it runs 400 times a day. That knowledge lives in the queries every team runs against the warehouse, every day.

The Single Origin MCP server gives Claude Code, Cursor or any MCP client a context graph built from every query your warehouse runs, so your agent can ask before it ships. It works once your warehouse's query history and metadata are loaded into Single Origin.

Three things nobody told the new hire

In an enterprise, tens of thousands of jobs from hundreds of teams share one warehouse. Here is what goes wrong, and the tools that fix it. To our knowledge, no other MCP server offers them. Names in the conversations are made up; the numbers in the callouts are real.

1. "It's just a rename"

A rename, a type change, a cast in the SELECT: each looks like cleanup in review. Column lineage tells you which models depend on a column. It doesn't tell you which queries actually read it in production, how often, or whether they filter on it.

A rename breaks those queries loudly. A type change breaks them quietly: the job still runs, and the numbers are wrong.

At one enterprise we work with, 125 jobs read and filter on a single column of one events table, along with 2,292 ad hoc queries, in 30 days.

you    › Can I rename legacy_status in orders_fact?
agent  ● table_column_readers(orders_fact, legacy_status)
         ↳ finance_export_job filters on it, 30 a day
agent  › Not yet: Finance's export filters on it.
         I'll update that job first, then rename it.

2. "I'll just build a new table"

Ask an agent for a metric and it builds a table. It can't search by what tables compute, so it doesn't know another team already built the same thing under a different name.

The same warehouse has 1,142 groups of tables built with the same logic.

you    › Build a daily revenue-by-region table.
agent  ● search_similar_queries(draft)
         ↳ marketing_geo_job already runs these joins
       ● similar_tables_by_transformation
         ↳ marketing.region_orders_daily is a duplicate
agent  › That table already exists. I'll point the
         dashboard at it instead of building a copy.

similar_tables_by_transformation compares the query that builds each table, formula by formula, ignoring column names.

3. "Why is the bill up?"

The bill arrives weeks later, summed by warehouse. By then thousands of changes have shipped, and nobody can say which one did it.

In the same 30 days, one job ran at 5× its usual cost in a single day: $565 more.

you    › Why did nightly_revenue_job cost 3× more?
agent  ● job_change_outcomes(nightly_revenue_job)
         ↳ Monday's version, PR #482: +$410 ± $60 a day
agent  › Monday's change casts order_date to text, so
         the date filter stops pruning. Reverting it.

job_change_outcomes ties each new version of a job's query to the pull request that most likely shipped it, and measures cost before and after against a control. recommendation_outcome does the same for fixes, at 7, 30 and 90 days.

How it knows: a graph built from query history

Single Origin reads your warehouse's query history and metadata, one day at a time. It never reads the rows in your tables. From that history it builds a context graph: jobs, the queries they run, the tables they read and write, the columns those queries touch, and what each of them costs day by day.

A catalog draws these lines all the same width. Query history knows the job behind one query a day costs more than the dashboard behind 2,400.

Raw query logs are too big to hand an agent: terabytes a day, mostly the same queries repeated. So the graph is distilled. A parser for each warehouse dialect strips literals and groups repeats into query signatures. Only new patterns are analyzed each day, and every recommendation is checked against a query profile. At Coinbase that meant parsing queries over 1,000 lines long, with 10 to 50 CTEs (case study). It works with Snowflake, Databricks, BigQuery, Redshift, Spark and Trino.

The same graph feeds your agent, the web app and pull request review.

Connect your agent

1. Load your query history. Share your warehouse's query history and metadata with Single Origin. We set this up with you.
2. Create a token. In the Single Origin web app, open Account → Access Tokens and click Create Token. Copy the token ID and secret.
3. Add the server to your client. For Claude Code, add this to .mcp.json:

{
  "mcpServers": {
    "singleorigin": {
      "type": "http",
      "url": "https://<company>-api.singleorigin.tech/mcp",
      "headers": {
        "Authorization": "Bearer <token_id>:<token_secret>"
      }
    }
  }
}

4. Ask a question about a job you know, such as "Which of my jobs cost more than usual yesterday?"

The MCP server docs cover Cursor and other clients. The recipes walk through questions like these step by step.

What's next

Agents are becoming the way data teams change their warehouses. Give yours, on day one, what a new hire takes months to learn. In a follow-up post we'll measure it: the same questions, asked of an agent with and without Single Origin, in tool calls, tokens, time and correct answers.

Want to try it on your own warehouse? Book a demo or read the docs.