[Part 5] Put MCP on Top of an Ontology and Your AI Changes

mcp-on-ontology-ai-change image 1

"Show me our Coupang sales."

If you've ever asked ChatGPT this after dropping in a CSV, you know how unreliable the answer is. Sometimes it counts only Wing sales, sometimes it adds Rocket Growth on top, and sometimes it answers based on EZAdmin OMS data. The same question returns a different number every time.

Bolting on RAG (retrieval-augmented generation) and feeding it documents doesn't fix this. Even if you document the context that "the Contribution Margin Rate on the Management dashboard and the actual Contribution Margin Rate in Performance by Product use different denominators," whether the AI actually pulls that document when the question comes in is down to luck.

For AI to properly handle the problems we've covered in this series — product name collisions (Part 2), inventory vs. shipment gaps (Part 3) and ad spend allocation (Part 4) — your data needs a structured definition of relationships (an Ontology) on top of it, and the AI needs to be able to access those relationships as tools.

That tool is MCP (Model Context Protocol).

Why RAG alone isn't enough

The limits of a document-based approach

Say you write up the context of your commerce data as documents and feed them into RAG.

Doc 1: "Net sales = total payments - Cafe24 refunds - Naver Pay refunds"
Doc 2: "The denominator in Performance by Product is the payment amount (before refunds)"
Doc 3: "Sabangnet data may have consistency issues"
Doc 4: "Coupang has three sources: Wing / RG / Supplier Hub"

No matter how well the documents are written, three problems remain.

Retrieval failure: When someone asks about "Anmod Pro profitability," there's no guarantee RAG will pull up Doc 1. The two are semantically related, but the keywords are different.
No way to combine context: Calculating Anmod Pro's Contribution Margin requires Doc 1 (net sales calculation), the ad spend allocation logic from Part 4 and the product mapping from Part 2 — all at once. RAG usually retrieves only the Top-K documents, and the odds that all three pieces land in the Top-K are low.
No access to live data: Documents only contain the definition — "net sales is calculated like this" — not the actual numbers. To answer "What are Anmod Pro's net sales this month?" you have to query the database.

What you actually need: definitions + data + execution

Requirement	RAG	MCP + Ontology
Metric definitions	Provided as documents (depends on retrieval)	Structured as metadata
Relationship definitions	Provided as documents (depends on retrieval)	Made explicit in the Ontology
Live data	Not possible	Direct database queries
Compound questions	Must combine multiple documents (unreliable)	Traverses the relationship graph (deterministic)

What MCP does

MCP is a protocol that lets AI call external tools. We run 4 MCP servers.

MCP server	Role	Key tools
MySQL MCP	Looks up user, connection and source metadata	query_user, query_connection
Trino MCP	Queries actual order / ad / inventory data (READ-ONLY)	trino_query
Airflow MCP	Checks ETL pipeline status	dag_runs, task_log
Sheets MCP	Reads Google Sheets data	sheets_get_data

The key point: when the AI gets a question, it queries the database directly. Instead of you uploading a CSV, it generates and runs the query that fits the question.

How the Ontology makes MCP smart

Example: "Show me our Coupang sales"

MCP alone, without an Ontology:

The AI fires a query at Trino, but it doesn't know which tables to query.

-- Query generated by the AI (uncertain)
SELECT SUM(payment_amount) FROM orders WHERE channel = 'coupang'
-- Wing only? Including RG? What about Supplier Hub? Based on EZAdmin?

There are 5 possible answers, and you get a different one every time.

Ontology + MCP:

The Ontology contains a definition of "Coupang sales."

Concept: Coupang sales
  Source of truth: [COUPANG_ADMIN_WING, COUPANG_ADMIN_RG, COUPANG_SUPPLIER_HUB]
  Aggregation: sum of all 3, deduplicated
  Metric: payment amount (excluding refunds/cancellations incurred)
  Note: may overlap with EZAdmin data; use channel API data

The AI refers to this definition and generates an accurate query.

SELECT SUM(payment_amount)
FROM (
  SELECT payment_amount FROM coupang_wing_orders WHERE ...
  UNION ALL
  SELECT payment_amount FROM coupang_rg_orders WHERE ...
  UNION ALL
  SELECT payment_amount FROM coupang_supplier_orders WHERE ...
)

Example: "Analyze why Laplace Pro's Contribution Margin dropped"

This single question draws on the entire series.

Product mapping (Part 2): Look up the 71 channel-specific option names linked to "Laplace Pro"
Metric selection (Part 2): Contribution Margin = payment amount - COGS - ad spend - fees - shipping - seller-paid shipping
Ad spend check (Part 4): Pull the ad spend allocated through 4-step matching from Source B
Channel comparison (Part 3): Contribution Margin trends for Cafe24 vs. Coupang vs. SmartStore
Root-cause reasoning: Higher ad spend? Rising COGS? More refunds? A problem with a specific channel?

Because the Ontology defines all of these relationships, the AI runs all 5 steps automatically from a single question.

Why a "Data for Claude" dashboard exists

In fact, some of our customers set up a separate dashboard just for the data they give to AI.

Dashboard: Data for Claude
Source A: Base product orders (10 fields, incl. payment amount, COGS, actual margin and shipping)
Source B: Ads (ad spend)
Granularity: date × sales channel × base product name
Aggregation: daily, from 2026-01-01

This dashboard isn't meant for people to look at. It provides a pre-joined dataset the AI can use to answer questions.

Why is this necessary?

The Management dashboard is based on net sales → the AI may mistake it for "sales"
Performance by Product is based on payment amount → yet another "sales"
Data for Claude is as close to the raw, unprocessed data as possible → the AI aggregates it directly as needed

Two-level CS tags change how AI interprets questions

CS data shows the impact of an Ontology just as clearly.

With flat tags:

Tags: "AS", "Return", "Refund", "Shipping"
→ AI: "There are 50 AS cases."  (What does that tell you?)

With a two-level tag tree:

Tag 1: AS/Laplace
Tag 2: Defect/Controller, Defect/Manufacturing, Defect/Charging
→ AI: "Of the 50 Laplace AS cases, controller defects are the most common at 28 (56%).
       That's up 15 cases from last month, so the quality issue should be investigated."

With a hierarchical tag structure (an Ontology), the AI can go from aggregation → comparison → root-cause reasoning in one pass.

Practical checklist: how an AX team should roll out MCP

Start with READ-ONLY — Let the AI read data but never modify it. Our Trino MCP, too, only allows SELECT/SHOW/DESCRIBE
Build a metadata MCP first — Let the AI look up table lists, column meanings and relationship definitions
Build a metric dictionary — Structure the exact formulas and context for "net sales," "payment amount" and "Contribution Margin"
Embed your source-of-truth policy in MCP — Define "Coupang sales = Wing + RG + Supplier Hub combined" at the code level
Have humans verify first — Check the AI's query results against your dashboard numbers. If they don't match, strengthen the Ontology

Wrapping up: Ontology → MCP → AI, in that order

Here's the flow we've covered in this series:

Part 1: Why you need an Ontology (defining data relationships)
  ↓
Part 2: Product name + metric collisions (different names for the same thing)
Part 3: OMS vs. channel API gaps (different numbers for the same order)
Part 4: 4-step ad spend allocation (creative → product matching)
  ↓
Part 5 (this post): AI executes the Ontology via MCP

Dropping in a CSV hands the AI raw ingredients. Adding RAG puts a recipe book next to it. Ontology + MCP sets up the whole kitchen: the AI cooks knowing where the ingredients are, where the tools are, and how each ingredient relates to the others.

If you're on a commerce AX team, set up your Ontology before you plug in AI. It's the fastest way there.

Making AI understand commerce data — Part 5 of the series (final)