Most AI demos I see follow the same pattern: a model writes text or code, a human reads it, and whether it actually holds up only shows later, at compile time, at deployment, in the worst case in production.

What has kept me thinking about the Model Context Protocol (MCP) for months is the chance to close that gap. Not by making the AI more cautious, but by having it work directly against a system that contradicts it the moment it gets something wrong.

I tested this with the Analytixus MCP server, on a task I would otherwise have done by hand: filling in missing references in a Lean Data Vault model. The result surprised me. Not because it was error-free, but because the errors showed up in the right place.

The Starting Point: A Model That’s Missing Something

The “Test-DBX” solution contains a Lean Data Vault model based on Microsoft’s Wide World Importers demo database: a bronze layer with the raw data and a silver layer with 31 Hist1 tables (historized facts) and 31 matching key tables. What was missing were the cross-references between these Hist1 tables: the foreign key relationships that have long existed in the source system but hadn’t yet been carried over into the DnAML model.

Exactly the kind of grunt work no one volunteers for: go through 31 tables, identify foreign keys, name them correctly, get them into the right format.

Step 1: Claude Connects and Immediately Knows What It Can Do

First the foundation: Claude is connected to the repository through the Analytixus MCP server and knows its tools before a single domain question is even asked: repository management, solutions, DnAML reference. This MCP server is the headline feature of Analytixus 0.7 (plus a few bug fixes), and it’s the prerequisite for everything that follows.

That’s the basic precondition for everything else: Claude doesn’t work “from the gut,” but against a clearly defined interface.

Step 2: “What Is DnAML?” Answered From the Source, Not From Training

DnAML, short for Data and Analytics Markup Language, is a homegrown, very young DSL. There’s no chance a language model has seen anything about it in its training data. And yet Claude describes its structure and syntax correctly, with all the building blocks (TABLE/VIEW, DOCUMENTATION, LOAD, ORIGINS, REFERENCES, CONSUMERS, GLOSSARY, SOURCES/FOLDER) and a working example.

The difference from a generic language-model answer: this explanation doesn’t come from training, but from a tool call against the DnAML reference that the MCP server provides. Claude fetched the knowledge live, it didn’t guess.

Step 3: Establishing Context

A look at the available solutions shows how casually this works: a quick question, a table of eight projects, done.

Step 4: The Actual Task: Deriving 69 References From Foreign Keys

Now it gets interesting. I describe the context: solution “Test-DBX,” source “WWI” already connected, bronze and silver layers already built following the Lean Data Vault pattern. The task: read all metadata recursively, analyze the foreign key relationships between the 31 Hist1 tables, and derive DnAML references from them.

Claude first reads in all the metadata, then analyzes the foreign key relationships and identifies 69 references across all Hist1 tables, including a clean summary per table.

Two details show that this isn’t simple pattern matching on column names:

– Nullable foreign keys are correctly marked as `INFERREDMEMBER`. So Claude distinguishes between mandatory and optional relationships.

– 13 Hist1 tables are explicitly identified as having no cross-references, because they are pure master-data / lookup tables (Countries, DeliveryMethods, PaymentMethods, etc.). That’s technically correct, and Claude says so, instead of inventing references where there are none.

At the end, the decisive question comes from Claude itself: *”Can you confirm the references as they are, or are there corrections?”* No automatic write-through, but a checkpoint before anything gets changed.

Step 5: The Correction, and How It Lands Immediately

And here comes the part that makes the difference. Claude had given every single reference a name. But that’s only technically correct when it’s a role-playing reference, that is, when several foreign keys of the same table point to the same target and therefore need to be distinguishable (e.g. `Delivery`/`Postal` for two references to `Cities_Key`, or `PrimaryContact`/`AlternateContact` for two references to `People_Key`). If only a single reference points to a target, it doesn’t need a name.

The response to that is the real proof: *”The concept is clear. […] I have no questions and will now create the V2.”* No follow-up question, no uncertainty: the rule is understood immediately, generalized correctly, and reapplied across all 69 references. Exactly the kind of correction you normally have to repeat several times before it sticks.

Step 6: The Closed Loop: Writing With Immediate Validation

The last and most important step: instead of just producing a file, Claude writes the `REFERENCES` blocks directly into the respective Hist1 tables in the repository through the MCP server, including the exact formatting rules (position after the `ORIGINS` block, comma placement).

The decisive point: this validation doesn’t come from Claude. It comes from Analytixus itself. On save, the engine checks the DnAML syntax. If something were wrong, the write would fail or return an error. So Claude gets a real, incorruptible feedback signal, not a “looks plausible.”

Only after this successful two-table pilot, with a green check on both, comes the go-ahead for the rest: *”Well done, the result is exactly as expected. Now write all remaining references into the respective Hist1 table.”*

Claude processes the remaining tables in parallel batches, and every single one is validated by Analytixus on write. In the end: all tables with a green check, not a single syntax error.

App Code Is Craftsmanship, Data & Analytics Is Series Production

At this point it’s worth asking why I have the AI work against a metadata tool like Analytixus at all, instead of simply letting it write the SQL directly. It could just as easily formulate the CREATE TABLE statements and ingest pipelines itself. But that’s exactly what I don’t want, and the reason has to do with the nature of the work.

For app coding, an LLM is in its element: every function is one of a kind, every requirement its own case, and there’s rarely one correct pattern that everything has to follow. Here, room to maneuver is even desirable, and the AI delivers superbly.

Data & Analytics is the opposite. Here I want a CREATE TABLE statement to look exactly the same for every single table, whether it’s about customers, invoices, or stock levels: the same technical columns, the same quoting, the same order, the same rules. This isn’t craftsmanship, it’s series production, where every part comes off the line following the same blueprint.

And this is exactly where a freely formulating LLM becomes a risk. When it writes a thousand CREATE TABLE statements, at some point it decides that a technical column is actually redundant for this one table. Or it stops quoting a name because it deemed it unnecessary in that spot. No ill intent, just the nature of the model: it doesn’t strive for determinism, it strives for plausible. But for series production, plausible isn’t good enough.

That’s why the division of labor this whole process demonstrates: the LLM does what it’s genuinely good at, namely understanding and analyzing which references exist in the domain. The deterministic generation of the code is handled by the engine, from metadata, following fixed rules, identical for every table. DnAML is the boundary between the two worlds: the AI thinks in metadata, not in DDL. It never gets its hands on the part that’s always the same in the first place.

Why This Convinces Me More Than Most Agent Demos

There were three moments in this process that together make the difference:

1. Knowledge from the source, not from training. The DnAML explanation came from a live tool call, not from half-learned trivia about a DSL that can’t even exist in the training corpus.

2. A correction that generalizes immediately. A single, clearly stated domain rule was understood and applied correctly across 69 references, without follow-up questions, without repetition.

3. Validation by the system, not by trust. Every change was checked by the Analytixus engine itself on write. That’s the real value of MCP in a tool like this: the AI doesn’t just get access, it gets a referee that tells it at every step whether it got it right.

In the end, all that was left for me was the role of reviewer at the right moments: confirm the reference list once, correct a naming convention once, release the pilot once. The actual grunt work (analyzing 31 tables, naming and writing 69 references correctly) took care of itself, without me typing a single line of DnAML myself.

And that’s exactly where the real question lies for me: how many of our AI workflows today really let the AI work against a referee that pushes back instantly, instead of just against our trust? How do you handle this in your projects?