So far in this series we’ve covered the security model and a real end-to-end example with Apex tools. Today, the third leg of the stool: data. Because an AI that can act but doesn’t know your real numbers is a confident intern with no access to the filing cabinet — full of energy, dangerous with specifics.
The fix has a name I use constantly in my Agentforce writing: grounding. And what I want to show you today is that with Data 360 (the platform formerly known as Data Cloud) exposed over MCP, grounding stops being an abstract promise and becomes something delightfully concrete: plain SQL, run by the AI, against your real data.
Why grounding beats guessing
Let me restate the problem in one sentence, because everything else follows from it: a language model on its own does not know your data — it knows language about data.
Ask an ungrounded model “which of our meters is behaving strangely this month?” and it will produce something fluent and plausible. Plausible is the trap. In a classroom, a student who guesses confidently is a teaching opportunity. In an energy company’s operations, a confident guess about meter readings is a real-world incident waiting to happen.
Grounding inverts this. Instead of asking the model to recall your data (it can’t), you give it a tool to query your data. The model’s job shrinks to what it’s genuinely good at — understanding the question, choosing the query, explaining the result — while the numbers come from the source of truth. Grounding beats guessing not because it makes the model smarter, but because it makes the model humbler: it looks things up.
The Query API: the quiet workhorse
Here’s the piece many people miss: standard Hosted MCP servers include Data 360 SQL access out of the box, through the Query API. No custom middleware, no export pipeline, no “let me build a REST wrapper first.” If your data is in Data 360, an MCP-connected AI client can query it with SQL.
Pause on how unglamorous and wonderful that is. SQL is the most battle-tested data interface humanity has produced. Every analyst can read it, every model has seen oceans of it, and — crucially for us — a SQL statement is inspectable. When the AI queries your data, you can read exactly what it asked. No black box between the question and the numbers.
For a beginner, the mental model is simple: Data 360 unifies your data into query-ready objects; the Query API is the door; MCP hands your AI assistant the key — with all the OAuth, scopes, and user-permission machinery from the first post still deciding what that key opens.
A real case: HanseWatt and the +64.6% meter
Theory again wants an example, so here’s mine. HanseWatt is a German utility scenario I built out — energy customers, meters, and a steady stream of consumption readings flowing into Data 360. The classic operational question: which meters are behaving abnormally?
The traditional answer involves dashboards, a data analyst, and someone remembering to look. My answer was a Calculated Insight written in plain SQL — an anomaly check comparing each meter’s latest consumption against its own trailing average. Not clever math. The kind of query you’d sketch on a whiteboard: current reading versus the recent baseline, flag the outliers.
Then I asked for anomalies through Claude, over MCP.
The result came back immediately: one meter sitting at +64.6% versus its trailing average. A real outlier in the data, surfaced by a plain SQL insight, retrieved by an AI assistant in conversation.
Two details of that moment matter more than the number:
- Zero UI clicks. I never opened a dashboard, never navigated Data 360’s interface, never built a report. The question went in as language; the grounded answer came out with the SQL-backed evidence attached.
- Zero credits burned. This entire proof ran without spending anything on agent orchestration. Just the Query API doing what query APIs do.
That second point deserves its own section, because I think it’s the most practical lesson in this post.
Prove your grounding with SQL before you burn agent credits
Here’s a discipline I now follow, and teach: before you build the agent, prove the grounding.
There’s a temptation, when the tooling is exciting, to start at the top — spin up an agent, wire in topics and actions, and iterate on the whole stack at once. When the answers come back wrong, you’re debugging everything simultaneously: was it the planner? The instructions? The action? The data? Meanwhile, every test conversation is consuming agent credits, so your debugging loop has a meter running. An expensive way to discover your data was the problem all along.
Flipping the order costs almost nothing:
- Write the SQL first. Build the Calculated Insight or the query that answers the business question. Run it directly. Is the answer right? Is the data fresh, unified, trustworthy?
- Prove it over MCP. Ask the question through the AI client and confirm it retrieves the same result via the Query API. This validates the whole grounding path — auth, scopes, query, response — at essentially zero cost.
- Only then build the agent experience on top. Now when something misbehaves, you know the data layer is solid, and you’re debugging only the layer you just added.
My +64.6% meter was found at step two. If I later want an agent that monitors meters, notifies field teams, and opens cases, I’ll build it on grounding I have already seen work — not grounding I’m hoping works. Twenty years of teaching gave me a deep respect for checking the foundations before building the next floor. This is that habit, applied to AI.
The honest boundaries
As always, let me tell you what this doesn’t solve. SQL grounding is only as good as the data underneath — if your Data 360 ingestion is stale or your identity resolution is messy, the AI will faithfully retrieve wrong numbers, with confidence. Grounding moves the trust problem from the model to the pipeline; it doesn’t delete it.
And a Calculated Insight like my anomaly check encodes a definition of abnormal (deviation from trailing average) that a human chose. The AI applies the definition well; deciding whether 64.6% deserves a truck roll or a shrug is still judgment. Same principle as the reseller onboarding limits: the tool retrieves and explains, the human decides what matters.
Where this leaves us
Three posts in, the shape of the MCP story is complete: a security model that makes AI access governable, Apex tools that let it act, and now SQL grounding that keeps it honest. Each layer is made of parts you already trust — OAuth, invocable methods, SQL — arranged so the AI walks through the same doors as everyone else.
If you take one thing from today, take the discipline: ground first, prove it cheaply with plain SQL over the Query API, and only then spend credits on the fancy layer. Your future debugging self will thank you, and so will whoever pays the bill.