AWS Builder Center

Builder Center

Bringing Snowflake Cortex Agents into Amazon QuickSuite with MCP

In this post, we'll show you how to connect Snowflake Cortex agents directly to Amazon QuickSuite using the Model Context Protocol (MCP), enabling business users to perform natural language querying with text-to-SQL and receive real-time answers from your Snowflake data warehouse without any data movement or engineering bottlenecks.

Alex Tarasov

Ketki Kothe  | Solutions Engineer at Snowflake
Louise De Leyritz  | Solutions Engineer at Snowflake
Alex Tarasov  | Sr. Solutions Architect, Startups at AWS

The Fragmentation Problem Nobody Talks About

Modern data teams have never had better tools. Snowflake stores and governs the data. Cortex brings AI natively into the warehouse. Amazon QuickSuite delivers dashboards and visualizations to business users. Each platform is powerful on its own.
But here's what we keep seeing across customer environments: analytics and AI are built in silos.
We saw this firsthand with a European payment processor serving 5,000+ merchants across the UK and Ireland. They had everything in place. Snowflake for data. QuickSuite for dashboards. A talented data team. But when their CFO asked during a board meeting, "What's our chargeback rate in Germany this quarter?" It took 3 days to answer. Not because the data didn't exist. Because the metric wasn't in any pre-built dashboard.
The data lived in Snowflake. The AI capabilities lived in Cortex. The business users lived in QuickSuite. And the gap between "I have a question about our data" and "here's the answer" was still filled with Slack messages to the data team, manual SQL queries, and 48-hour turnaround times.
Their merchant analytics portal was collapsing. SQL Server queries timing out after 45+ seconds. QuickSuite dashboards requiring SPICE (Super-fast, Parallel, In-memory Calculation Engine) refresh every 2 hours. The data team fielding 200+ Slack requests per week. Simple questions taking two full days to answer.
Dashboards solve the known questions, the ones someone anticipated and built a chart for. But the real value of data comes from the unknown questions. The follow-ups in a board meeting. The ad-hoc cuts of data during a pipeline review. The "what if we look at this differently?" moments that drive decisions.
The missing piece isn't more dashboards. It's a way to let business users ask questions in natural language, have AI generate and execute the right SQL against live data, and return answers instantly, all within the BI tool they already use.

A New Way: AI-Driven Analytics Without the Middleware

What if a QuickSuite user could type "What are our top 10 merchants by revenue this quarter?" and get an accurate, real-time answer pulled directly from Snowflake, with no data pipelines, no API middleware, and no engineering involvement?
That's exactly what becomes possible when you combine three things:
Snowflake Cortex Agents → AI agents that understand your data model and generate accurate SQL from natural language
Model Context Protocol (MCP) → An open standard that lets AI tools communicate with external services over a unified interface
Amazon QuickSuite's MCP integration → Native support for connecting to MCP-compatible servers, including one hosted in Snowflake
This isn't just an integration. It's an AI-driven analytics workflow where the intelligence layer lives with the data, the BI layer stays where business users already work, and MCP bridges them without custom plumbing.
We ran a 3-hour workshop with this payment processor to prove this could work. Here's what we built.

Prerequisites

To follow along with this architecture, you'll need:
  • A Snowflake Enterprise (or higher) account with Cortex enabled
  • Amazon Quick subscription with author access
  • Snowflake roles with permissions to create integrations, agents, and semantic views
  • Basic familiarity with Snowflake SQL and OAuth configuration

High-Level Architecture

Here's how the system works, and more importantly, why each component exists.
The following diagram shows the data flow from Amazon QuickSuite at the top (BI consumption layer), through an OAuth-authenticated MCP/HTTPS connection to the Snowflake MCP Server, which routes to the Cortex Agent for AI orchestration, then to Cortex Analyst for text-to-SQL generation, which queries against the Semantic View (business logic and data model), ultimately hitting the source tables in Snowflake.
Amazon QuickSuite (BI consumption layer)
|
| OAuth 2.0 authentication
| MCP Protocol (HTTPS)
v
Snowflake MCP Server (API exposure layer)
|
v
Cortex Agent (AI orchestration)
|
v
Cortex Analyst (text-to-SQL engine)
|
v
Semantic View (business logic + data model)
|
v
Tables in Snowflake (source of truth)

The flow:

  1. User asks a question in QuickSuite, plain English, no SQL
  2. QuickSuite sends the question to Snowflake's MCP Server over HTTPS, authenticated via OAuth
  3. The MCP Server routes it to the Cortex Agent
  4. The Cortex Agent consults the Semantic View, a declarative layer that encodes table relationships, metric definitions, business logic, and pre-validated query patterns
  5. Cortex Analyst generates SQL, the agent executes it on a Snowflake warehouse
  6. The answer flows back through MCP to QuickSuite. Only the result set leaves Snowflake, never the raw data

Why each layer matters:

Semantic View exists because text-to-SQL without context is unreliable. When someone asks about "revenue," the system needs to know that means SUM(transaction_amount) from the transactions table, not estimated_value from the pipeline table. The Semantic View encodes this business logic declaratively, along with table relationships, dimension hierarchies, and verified queries (pre-validated question-SQL pairs that guarantee accuracy).
For this payment processor, we modeled merchant performance. Dimensions like merchant_id, region, category, merchant_tier. Metrics like total_transactions, total_volume, chargeback_rate_pct. When a user asks "What's the chargeback rate in Germany?" Cortex Analyst knows exactly which columns to query and how to aggregate them.
Workshop Insight: We initially built the semantic view without verified queries. Accuracy was 72%. After adding verified queries for the top 20 merchant questions ("top 10 by revenue," "chargeback rate by region"), accuracy jumped to 89%. The lesson: combine LLM flexibility with vetted queries.
Cortex Agent provides an orchestration layer between the user's question and the SQL engine. It handles intent interpretation, tool selection, query execution, and response formatting, all within Snowflake's compute and governance boundary.
For the workshop, we configured the agent with a system prompt tailored to merchant analytics: "You are a helpful assistant for merchant performance analytics. Format currency as GBP. Always provide clear, actionable insights."
MCP Server exists because the agent needs to be accessible outside Snowflake. MCP is an open protocol, not proprietary, which means this same endpoint could serve QuickSuite today and Slack, Teams, or a custom app tomorrow. No per-client integration work required.
OAuth Integration exists because security can't be an afterthought. We configured Snowflake's OAuth integration to issue scoped tokens to QuickSuite users, ensuring every request is authenticated and authorized against Snowflake's role-based access control. No passwords stored externally, no shared secrets exposed to end users.
We have published extensive step-by-step guide  on how to configure and enable Snowflake Cortex MCP server in Amazon QuickSuite.

Key Design Decisions

This is where the architecture choices matter, and where we see teams make different trade-offs depending on their environment.

Why Cortex instead of an external LLM?

The most common alternative we see is calling an external LLM (via Amazon Bedrock, OpenAI, etc.) to generate SQL, then executing it against Snowflake. It works, but it introduces three problems:
Data context leaves the warehouse. You're sending schema information, sample data, and business logic to an external model. For the payment processor handling regulated financial data, this was a non-starter.
Latency increases. External API round-trips add 2-5 seconds per query on top of the SQL execution time.
Governance gaps. There's no unified audit trail when the AI reasoning happens outside the data platform.
With Cortex, the AI lives inside Snowflake. The Semantic View, the SQL generation, the query execution, everything stays within the same governance, security, and compute boundary. One audit trail. One set of access controls. No data movement.

Why MCP instead of a custom API?

You could build a Lambda + API Gateway wrapper around the Cortex Agent. Some teams do. But MCP offers two advantages:
Standardization. MCP is an open protocol. QuickSuite, Claude Desktop, Cursor, and a growing list of clients support it natively. One MCP server can serve all of them without per-client integration work.
Managed infrastructure. Snowflake's managed MCP server handles HTTPS, authentication, and agent routing. No Lambda functions to maintain, no API Gateway to configure, no cold starts to worry about.

Why Semantic Views instead of RAG on schema?

The trade-off here is upfront data modeling (Semantic Views) versus dynamic schema discovery (RAG over INFORMATION_SCHEMA).
We chose Semantic Views because:
Column names and aggregations mapped to exact business logic. For example, a revenue could be defined as SUM(transaction_amount) WHERE status = 'approved' instead of LLM trying to guess the correct formula.
Verified queries guarantee accuracy for critical metrics. Chargeback rate, merchant lifetime value, transaction velocity. These need to be right, not approximately right.
Portable to other tools. The same semantic view works with Tableau, Looker, Hex, or any SQL tool. You're not locked into one BI platform.
The downside: 40% of project time spent on modeling. But the alternative, letting the LLM guess what "revenue" means, would have killed trust in week one.

Patterns and Use Cases

The architecture is domain-agnostic. Here's how it applies across industries we work with:
Example: Payment Processing
A business analyst asks: "What are our top 10 merchants by revenue in the UK this quarter?"
Cortex generates SQL that filters by region, aggregates transaction amounts for approved transactions only (no refunds), and returns a ranked list. The Semantic View ensures "revenue" maps to the correct calculation.
Before: 48 hours (Slack the data team, wait for SQL, wait for results)
After: 10 seconds
The same pattern applies to retail, financial services, or any domain with structured data and business users who don't want to wait in an analyst queue.

What Makes This Powerful

Stepping back, here's what this architecture enables:
Natural language to SQL to insight. No code, no analyst bottleneck, no data movement.
Intelligence stays with the data. Cortex runs inside Snowflake, so governance, security, and audit are unified.
Business users self-serve. In the BI tool they already know, without learning SQL or switching platforms.
One MCP server, many clients. The same endpoint serves QuickSuite today and could serve Slack, Teams, or custom apps tomorrow.
Verified queries build trust. Pre-validated SQL for critical metrics ensures the AI's answers match what a human analyst would produce.
The net effect is a dramatic reduction in time-to-insight. Questions that used to take hours (ask the data team, wait for SQL, wait for formatting, wait for delivery) now take seconds.

Challenges and Considerations

No architecture is without trade-offs. Here's what to think about before deploying this in production:

Cost model

There are three cost vectors: Snowflake warehouse compute (for query execution), Cortex AI credits (for the agent and text-to-SQL), and QuickSuite user licenses. For most workloads, the Cortex and compute costs are modest, comparable to running the same queries manually. But high-volume deployments (hundreds of users, thousands of daily queries) should model costs before scaling.

Security and row-level access

OAuth tokens are scoped to a Snowflake role, which controls what tables and schemas the user can access. For fine-grained access (e.g., a merchant should only see their own transactions, not competitors'), you'll need Snowflake's row access policies or secure views layered underneath the Semantic View.
For production deployments with multi-tenant data, you would implement something like:
1
2
3
CREATE ROW ACCESS POLICY merchant_isolation AS (merchant_id VARCHAR)
RETURNS BOOLEAN ->
CURRENT_USER() = 'ADMIN' OR merchant_id = CURRENT_USER()
This ensures that even if the agent generates SQL that queries all merchants, Snowflake's access policy filters results to only the authenticated user's data.

Latency expectations

Most queries return in 3-10 seconds:
  • LLM text-to-SQL generation: 1-2 seconds
  • SQL execution on Snowflake: 1-5 seconds for simple aggregations, up to 10 seconds for complex multi-table joins
  • Response formatting: < 1 second
Complex multi-join queries on undersized warehouses can take longer. Right-sizing the warehouse keeps the experience fast.
QuickSuite currently imposes a 30 seconds timeout on MCP integrations. If queries consistently exceed this threshold, consider:
  • Pre-aggregating heavy tables into a curated layer
  • Adding verified queries for known-slow questions (stores pre-computed results)
  • Scaling the warehouse to MEDIUM or LARGE for faster execution

Semantic view quality

The quality of your semantic view directly determines agent accuracy. In the workshop, we budgeted 40% of time for data modeling, and it required 3 iterations to get right.
A common pitfall: marking columns as FACTS when they should be METRICS. For example, marking transaction_amount as a FACT means the system doesn't know whether to COUNT, SUM, or AVG when a user asks about "total revenue."
The fix is defining it as a METRIC in the semantic view YAML:
1
2
3
4
metrics:
total_volume:
expr: SUM(transaction_amount)
description: "Total transaction volume in GBP. Aggregated as SUM."
Don't rush this step. The semantic view is the foundation everything else builds on.

What Comes Next

Both Snowflake and AWS are exploring what's possible next. Here are some directions we anticipate:
Embedded conversational analytics. We anticipate AI agents embedded directly within QuickSuite dashboards, so users could ask follow-up questions in context alongside existing charts.
Multi-agent workflows. Chaining Cortex Agents together (e.g., one for sales data, one for finance data) so a single question could draw from multiple domains.
Automated insight generation. Agents that could proactively surface anomalies and trends, pushing insights to QuickSuite or Slack without waiting for a user to ask.
Deeper MCP ecosystem. As more tools adopt MCP, the same Snowflake agent can serve QuickSuite, other BI tools, and custom applications through a single endpoint.
The foundational pattern (semantic layer + AI agent + MCP exposure + OAuth security) is the building block for all of these.

Resources

# amazon-quick-suite# mcp# generative-ai# data-integration# aws-partners
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article