MCP for Data Engineers: Model Context Protocol Without the Hype

    What the Model Context Protocol actually is, why warehouse and pipeline tools fit it, and how to expose data systems to an AI assistant without turning SQL into a write-anything chatbot.

    By Adriano Sanges--12 min read
    MCP
    AI engineering
    data engineering
    LLM
    agents
    warehouse
    tooling

    TL;DR: MCP (Model Context Protocol) is an open protocol for connecting an AI app to tools and data sources through a standard server. For data engineers it is a way to let an assistant inspect schemas, run read-only queries, and fetch pipeline metadata — not a replacement for dbt, Airflow, or your warehouse IAM. Treat MCP servers like any other production API: least privilege, evals, and no write tools until you can prove they are safe.

    Model Context Protocol (MCP) is a standard for exposing tools, resources, and prompts to an LLM application. The host (Claude Desktop, Cursor, a custom agent) talks to one or more MCP servers. Each server advertises what it can do. The model never gets raw database credentials in the prompt; it asks the host to call a named tool, and the server executes that call under your auth.

    That is the whole idea. It is not a new warehouse. It is not an Airbyte connector mill. It is closer to “OpenAPI for assistants,” with a long-lived process instead of a one-shot HTTP spec dump.

    If you already ship production LLM systems, MCP sits in the tool-use layer: the same layer as agents, with the same failure modes (wrong tool, too many steps, leaked data). If you are mapping a career path into that work, the AI Engineer roadmap is the structured version of this article.

    Why data engineers should care

    Warehouse work is already tool-shaped: list datasets, describe a table, preview partitions, fetch the last Airflow run, open a dbt manifest node. Today that happens in six UIs. An MCP server can wrap the read path so an assistant answers “which column did we add to fct_orders last week?” without pasting a service account into chat.

    The useful jobs are boring:

    • Discovery. “What exists?” beats hallucinated table names.
    • Grounded SQL. Generate a query against a live schema, then run it in a sandbox.
    • Ops lookup. DAG status, freshness, row counts — the questions on-call already types into a console.
    • Docs that do not rot. A resource that returns the current information_schema is more honest than a wiki page from 2024.

    The jobs that are not useful yet: letting the model DROP TABLE, trigger prod DAGs, or rotate secrets. That is not “AI engineering.” That is an incident.

    Host, client, server — in warehouse language

    Keep three roles straight:

    Role Analogy Example
    Host The app the human uses Claude Desktop, Cursor, an internal agent UI
    Client The host’s connection to one server One session per MCP server
    Server Your process that wraps a system A Python process with BigQuery read credentials

    A server typically exposes:

    • Tools — functions the model may invoke (list_datasets, run_readonly_sql).
    • Resources — fetchable documents (schema://project.dataset.table).
    • Prompts — optional templates the host can offer the user.

    You implement a server; you do not fork the host. The protocol is documented at modelcontextprotocol.io. Do not copy SDK method names from memory into production code — pin a version and read that version’s spec.

    A read-only warehouse server (the only default that is sane)

    Design the first server as if it will be screenshotted in a postmortem.

    1. Auth is yours. The server holds a service account (or user OAuth) with roles/bigquery.dataViewer (or the warehouse equivalent). The model never sees the key.
    2. Every SQL tool is SELECT-only. Parse or allowlist statements. Reject INSERT, MERGE, CREATE, DROP, EXPORT DATA, and script blocks that contain them.
    3. Cap bytes and rows. BigQuery: dry-run, max bytes billed, LIMIT injected if missing. Snowflake: warehouse size + statement timeout. This is the same discipline as window-function cost notes.
    4. Scope to one project/dataset. An MCP tool named run_sql on the entire org is a data leak with extra steps.
    5. Log the tool name, arguments, identity, and row count. You will need this when someone asks why the assistant quoted a PII column.

    A sketch of the contract — not a copy-paste SDK:

    tools:
  - list_datasets() -> [{id, location}]
  - list_tables(dataset) -> [{id, type, partition_column?}]
  - get_schema(dataset, table) -> [{name, type, mode, description}]
  - run_readonly_sql(sql, max_rows=100) -> {rows, bytes_processed, job_id}

    If you cannot explain run_readonly_sql to security in one sentence, do not ship it.

    MCP is not your transformation layer

    dbt still owns SQL that must be tested and reviewed. MCP can read a compiled model or a manifest.json node; it should not be how you deploy marts. Same split as analytics engineering with dbt: humans (and CI) write the layer that other humans depend on. Assistants help you inspect.

    Airflow / Dagster stay the orchestrators. An MCP tool that returns the last failed task is fine. An MCP tool that airflow dags trigger production is a page waiting to happen unless it is gated, ticketed, and replay-safe.

    Evals, not vibes

    Tool-using models fail in specific ways. Test them the same way you test RAG:

    • Golden questions with known tables (“row count of stg_orders yesterday”).
    • Forbidden actions (write SQL, out-of-scope dataset) must be refused.
    • Schema drift. Rename a column in staging and assert the assistant does not keep using the old name after get_schema.
    • Cost. A question that should dry-run at 12 MB must not scan 2 TB because the model omitted the partition filter.

    If you have no eval set, you have a demo. The LLM evaluation section of the AI roadmap is the longer treatment.

    What to ignore

    Vendor posts will try to sell you “MCP connectors” the way they sold you “AI-ready pipelines.” A connector that wraps SaaS APIs you already extract with Fivetran or Airbyte does not need a new protocol in the warehouse path. Start from your catalog and your IAM. Add SaaS MCP servers only when the host is a developer tool, not when you are duplicating ELT.

    A practical rollout

    1. One read-only server, one dataset, one host (your laptop).
    2. Two weeks of personal use. Keep a log of wrong-table incidents.
    3. Add get_schema + dry-run before you add run_readonly_sql.
    4. Put the server behind the same SSO you use for the warehouse console.
    5. Only then discuss a write tool — and make it open a PR, not mutate prod.

    Hands-on follow-up: the LLM agent project is where tool use and failure modes get built on purpose, not pasted from a changelog.

    Frequently Asked Questions

    What is MCP in data engineering?

    MCP (Model Context Protocol) is an open standard that lets an AI application call tools and read resources from a server you run. In data engineering that usually means listing datasets, fetching table schemas, and running tightly scoped read-only queries — under IAM you control, not credentials pasted into a chat.

    Is MCP a replacement for dbt or Airflow?

    No. dbt remains the tested transformation layer; Airflow or Dagster remain the orchestrators. MCP is an interface for assistants to inspect those systems. Generating SQL in chat is not the same as merging a reviewed model.

    How do I expose BigQuery or Snowflake to Claude or Cursor safely?

    Run an MCP server with a read-only role, allowlist SELECT, cap bytes and rows, restrict the dataset, and log every tool call. Do not grant the host a write role “so it can be more helpful.”

    What is the difference between MCP tools and an agent?

    An agent is a loop that chooses tools until it stops. MCP is how those tools are described and invoked. You can use MCP from a single-shot chat or from a multi-step agent. The protocol does not make the loop safe; your tool design and evals do.

    Should I let an LLM run SQL in production?

    Only if the statement is read-only, scoped, cost-capped, and audited — the same bar you would set for a junior analyst with a shared BI user. Writes belong in reviewed code, not in a tool the model can call when it is confused.

    About the Author

    Adriano Sanges is a data engineer and the creator of dataskew.io. He builds production data platforms with Airflow, dbt, Spark and cloud warehouses, and writes hands-on guides to help aspiring data engineers advance their careers.

    LinkedIn · Website

    Related Articles

    Production LLM Engineering for Data Engineers: Evals, RAG, Agents, and LLMOps

    A practical map of what it takes to run LLM systems in production: evaluation, retrieval, agents, and the ops discipline that keeps them reliable and affordable. Written for data engineers moving into AI.

    10 min read

    Apache Airflow for Data Engineers: DAGs, Operators, and Production Patterns (2026)

    How Apache Airflow works for data engineers: DAGs, operators, the scheduler, and the production patterns (idempotency, backfills, sensors) that keep pipelines reliable.

    11 min read

    Apache Spark for Data Engineers: How It Works and When to Use It (2026)

    Apache Spark for data engineers: the execution model (driver, executors, shuffles), DataFrames vs RDDs, production best practices, and when Spark beats SQL or a warehouse.

    11 min read

    Try the related project

    LLM Agent with Tools and Failure-Mode Evaluation

    Build an agent that plans, calls real tools (function calling), manages memory, and recovers from failures, then evaluate it on its trajectory and failure modes, not just happy-path demos.

    Start this projectBrowse all projects