How Workato Built Enterprise Data MCP

The answers to your business questions lie in your data, but how effectively can dashboards surface them? My guess: not very.

Dashboards answer yesterday’s questions. They’re built to address the queries you had before you built them, and require a rebuild the moment your business focus shifts.

That’s not sustainable and, with AI, dashboards won’t remain the best way to get answers from your data for long. So my team spent the last few years building something different: a way to turn that static process into a real-time conversation with a large language model, powered by an Enterprise MCP that answers 90% of our company’s data questions in seconds.

We call it Enterprise Data by Workato MCP. And I believe it’s the natural next evolution of business intelligence.

The Vision Behind Enterprise Data MCP

When my team started building the MCP, replacing traditional business intelligence workflows with AI felt unrealistic. Even people convinced AI was creating a seismic shift were skeptical we’d find a way to generate fact-based, accurate, repeatable answers to unpredictable business questions.

But business questions don’t arrive at the data team as dashboard requests, they arrive as conversation:

  • “Why did pipeline drop in EMEA last quarter?”
  • “Which customer segments have the highest expansion rates?”
  • “What products are contributing most to churn?”

So I asked myself: why do we keep translating these into dashboards? Why can’t the data just answer the question?

A person shouldn’t need to know where to find the data, have permission to build a report, or understand table structures to get an answer to a clear business question. And ideally they’d get this answer right away, not days later when the dashboard is complete.

My vision was different: just a handful of gold-layer dashboards, built and meticulously maintained by my team to Medallion Architecture standards, feeding a knowledge base that AI could query directly.

What was Enterprise Data MCP’s Scope? 

When I first proposed the vision, conversational BI was only one piece of a much larger data strategy. There were opportunities across data administration, data engineering, and analytics too.

But as discussions progressed, one thing became clear: everyone up to top executives wanted a way to talk to their data, because they share the same problem: how do I get the information I need right now?

The project needed:

End user variation

We needed to group end user groups across both functions (initially product, sales, marketing, and customer success) and levels, from individual contributors through executives.

Bulletproof data

We needed to verify data and match the appropriate Snowflake tables to the expected questions.

An accessible interface

We needed to decide whether users would use Claude or Slack to access the MCP.

Implementation Challenges

Data agents, AI-powered analytics tools, and conversational BI platforms have existed for years. Many companies have experimented with them, but most have struggled to make them consistently reliable.

It’s not difficult to connect an LLM to a data set and ask it questions. The hard part is ensuring the model actually understands the business—and that’s why so many people were skeptical of our vision.

When a sales leader asks about a pipeline, for instance, does the system know which pipeline definition to use? Without that understanding, conversational analytics quickly becomes a trust problem.

We needed to anticipate all potential queries, and define ways of answering them—and we needed the MCP to admit when a question was outside its scope instead of hallucinating an answer.

We needed a way to anonymously tally the questions people asked the MCP, so we could expand the scope of queries it could answer. And we needed a feedback loop to feed back into the MCP.

Many people believed the problem was too difficult to solve. Building a proof of concept was one thing; building a system that consistently produced accurate answers in production was something else entirely.

When challenged, one other engineer in my team and I doubled down. We put our heads down and ignored the noise, because we knew the semantic model was the brain behind everything.

The foundational question was: how do you create a semantic understanding of the business that an AI system can reliably reason about and a semantic model that can be automated and can be scalable and easily maintainable? That became the focus.

How the MCP Was Built

The most important component isn’t the AI model, it’s the harness that enables the model to understand the business correctly. That’s the lesson we learned building Workato’s Enterprise Data MCP.

The conversational experience is what users see, but the semantic architecture underneath is what makes it trustworthy. And that’s the part we’ll explore next.

Here’s an overview of the architectural levels and components.

  1. MCP clients are the interaction layer for end users or AI agents.
  2. The semantic layer provides the business context and definitions built on Workato.
  3. MCP intelligence executes the query built on Workato.
  4. Data sources provide the data.
  5. The outputs resurface the data in the MCP client.

To build the semantic model, Workato built recipes to crawl our existing business intelligence workbooks, extract the metric definitions, calculated fields, and filters buried in them, and auto-generate VQRs from that logic. With this method, years of institutional knowledge became a VQR library in hours. We also look at query history to assess which queries can be qualified to be a VQR and upsert them to the VQR library. The same pipeline runs on a schedule and on schema drift, deploying updates through version control.

The semantic and MCP intelligence layers auto-load agent instructions, and execute the core workflow and SQL classification rules. Here’s an example of a call using the Enterprise Data by Workato MCP:

Every question primarily takes one of three paths:

  • If it matches a Verified Query Repository (VQR) a pre-validated question-to-SQL pattern the answer comes back with high confidence.
  • If it’s close to an existing VQR, the model adapts that query.
  • Only when neither applies does the LLM generate SQL from the semantic model directly, and those queries get flagged for verification.

This tiering is what keeps answers deterministic where it matters.

Put simply: VQRs are what give us accuracy – every answer that matches one is backed by validated SQL, not a guess. And Workato tools with progressive disclosure are what give us determinism – every question moves through the same fixed sequence of tools and loads only the context it needs, so the same question produces the same answer every time.

How to Improve the MCP

The Workato’s Enterprise Data MCP semantic model includes machinery that makes the system better over time.

Observability

We log every question, which path answered it (VQR, adapted VQR, or LLM-generated SQL), and whether it succeeded. That metadata tells us exactly where the gaps are and drives what we tune next.

Self-healing semantic models

Gold-layer tables change. Left alone, that drift silently breaks the semantic model and you get wrong answers or none at all. We’re automating the updates – VQRs, relationships, and table definitions – with a human-in-the-loop review on every pull request before it merges.

Self-learning semantic models

An onboarding agent watches for new gold-layer tables, adds them to the semantic model, and suggests VQRs for them – checking against existing metrics and VQRs so nothing gets duplicated.

Synthetic VQRs

Good LLM-generated queries get promoted into the VQR library after validation. Every novel question a user asks can become a verified answer for the next user. The system compounds.

How to Cut Usage Costs and Latency 

A big lesson we learned over time was how to manage costs. The production version loads the full semantic model on every query – about 185K tokens and 4–6 seconds per question. Two successors change that economics:

  • Progressive disclosure (beta) loads an index first, then only the context the question needs
  • Context graph (in development) is cache-first: a cache hit answers in ~200ms, and every query it answers makes the next one faster.

The same question and correct answer, but at 80–96% lower cost.

Warehouse cost intelligence

The same approach pays for itself on the warehouse side too. We ingested Snowflake’s own ACCOUNT_USAGE metadata into a semantic model, so cost questions can be asked in plain language. which warehouses are sitting idle, which queries are spilling to disk, where spend has no owner. That analysis surfaced zombie warehouses and inefficient queries and has driven significant  annual Snowflake savings insight the warehouse vendor has little incentive to build for you.

Enterprise Data MCP Results by the Numbers

Today Enterprise Data by Workato MCP is Workato’s most-used internal MCP. A simple data question previously took anywhere between 5 minutes to 10 days to answer, and fewer than 20% of users could self-serve. Today 90% of user questions are answered in seconds, in the tool where they were asked.

The most recent version:

  • Has access to 138 tables
  • Tracks 214 metrics
  • Manages 121 relationships
  • Can answer 1,032 verified queries (up 7x from an initial list of 149)
  • Serves 900+ users across the company
  • Has executed 40,000+ queries since the June 2026 
  • Runs at a ~6–7% weekly failure rate, down from ~30% at launch

The MCP can answer simple factual questions, such as “What’s Acme’s task usage this month?”, which would interest the account manager. It also answers complex analytical questions, such as “Which accounts show severe usage decreases this month and have open support tickets—potential churn signals?”, which would interest customer success leadership and influence business strategy.

To enable Customer 360, Workato connected Enterprise Data MCP to our Snowflake, Salesforce, Gong, Gmail, and Slack MCPs. Users can quickly access an account’s ARR and consumption data from Snowflake, open opportunities from Salesforce, recent call summaries from Gong, and the latest exec threads from Gmail. That picture wasn’t possible before, and it changed how our account teams work.

At most companies, accessing data still requires a professional translation layer. Business users must translate questions into analyst requests, which analysts translate into queries to build the dashboards and reports that business users have come to expect. This process takes time.

We found that Data MCP removes that translation layer. The question in your head becomes the question you ask, and the answer comes back to you immediately.

Because it’s so easy, the number of questions worth exploring also expands dramatically. Curiosity is rewarded, not punished, as insights become accessible on demand.

The biggest value prop we started seeing was to connect this Enterprise data MCP to other MCP’s like gmail, slack, Gong , we are able to create a true customer 360 analysis which was not possible before. This completely changed how we do business.

To learn more, check out this webinar with Workato and Dispatch.