Data Engineering Layer between MCP and Agent

MCP lets an agent pull data from anywhere. But pulling data from MCP is the easy part.

The hard part is that a model has a finite context window and limited working memory, and most MCP servers hand it raw, unshaped data like a giant JSON blob the model has to parse, hold, and reason over all at once. It answers confidently, and often wrongly.

The fix is not a bigger model or a cleverer prompt. It is ordinary data engineering applied behind the MCP boundary, so that what the agent receives is already precise, typed, and scoped.

This talk walks through that idea with a working open-source data warehouse stack that help imporve quality and confidence of anwers and help in self-learning:

The failure mode, if measured would be an MCP tool returns a few thousand rows of JSON, the agent burns its context budget on parsing, and gives a wrong answer. We count the tokens. The mental shift we need is to treat retrieval as a query problem, not a data sorce or more data for context problem.

With a minimal FOSS stack: DuckDB + Parquet for storage, a medallion layout (raw to cleaned to production) so the production layer is the only thing the agent touches, and Dagster/dbt to keep it reproducible. Designing the MCP tool surface requires us to keep exposure scoped, parameterised queries and pre-aggregated views instead of raw tables.

We will also share about limits for example, when this is an overkill, and when a single flat file is genuinely enough.

I built this stack for a large grant funding dataset and hit every one of these walls
in production. This talk shares the solution that works and works well.

• Why agent reliability is usually a data-shaping problem, not a model problem.

• A concrete before/after: the same MCP tool, raw blob vs scoped query, with token counts
  and accuracy side by side.

• A repeatable open-source date modelling pattern. DuckDB + Parquet + a medallion layout + Dagster/dbt that you can run locally and apply to any dataset (logs, records, product tables).

• How to design MCP tools that return scoped queries and pre-aggregated views instead of raw tables.

• A clear sense of when this approach is worth it and when it’s an overkill.