Build and Connect Your Own MCP Server to Amazon Quick
Build and Connect Your Own MCP Server to Amazon Quick - Connect your external MCP tools and external agents to Amazon Quick
A Hands-On Workshop Guide
Co-Authors : David Girling , Eugene Thomas , Chaitanya Shah
Introduction
We are living in a moment where AI is no longer just a tool for answering questions, it is becoming an agentic layer across the entire enterprise. Teams want AI agents that do not just retrieve information but actually do things: submit a timesheet, update a customer record, create a support ticket, query an org chart, check a leave balance all from a single conversation, without switching between a dozen different applications.
Amazon Quick is built for exactly this. It is a unified agentic AI workspace that empowers teams to analyze data, build intelligent agents, discover enterprise knowledge, and automate workflows all in one place. It combines the power of business intelligence with AI assistance through natural language, giving every user in your organization a capable AI teammate.
But Amazon Quick is only as powerful as the tools it can reach. Out of the box, it connects to a growing ecosystem of popular services. But every organization has its own systems internal HR platforms, proprietary CRMs, custom ERP integrations, legacy APIs, SaaS tools with unique configurations. For Amazon Quick's AI agents to truly serve your business, they need to reach your systems.
That is where Model Context Protocol (MCP) comes in.
MCP is an open standard that defines how AI applications connect to external tools, data sources, and services. Think of it like USB-C for AI integrations a universal interface that lets any AI system plug into compatible resources through a consistent protocol. Amazon Quick supports MCP integrations for action execution, data access, and AI agent integration.
When you configure an MCP integration in Amazon Quick, Quick acts as an MCP client and connects to your MCP server endpoint to access the tools you expose. After that connection is in place, Amazon Quick AI agents and automations can invoke your tools to retrieve data and run actions in your product, using the customer's authentication, authorization, and governance controls.
This workshop teaches you how to build that MCP server and connect it to Amazon Quick two different ways, depending on where you are starting from.

Why This Matters: The Pain Points MCP Solves
If you have tried to connect an AI agent to real business systems, you have likely run into a wall or several. These are the most common friction points that slow teams down, and exactly what this workshop addresses.
No Standard Integration Contract
Every AI platform has historically had its own way of defining tools, handling authentication, and routing requests. If you are an ISV, you might build a custom connector for one AI platform, only to find that a different customer uses a different platform entirely and you have to start over. There is no reusable pattern, no shared protocol, no way to build once and deploy everywhere.
MCP solves this. It gives you a standard contract: define your tools once, publish a stable endpoint, and any MCP-compatible AI platform including Amazon Quick can connect to it. One integration works for all your customers.
Authentication Complexity
Enterprise systems require OAuth, JWT tokens, scoped permissions, and careful credential management. You need to handle both inbound authentication (how Amazon Quick authenticates to your MCP server) and outbound authorization (how your MCP server authenticates to the underlying APIs it wraps). Wiring this up manually for every integration is error-prone and time-consuming.
Amazon Quick MCP integrations support three authentication patterns:
- User authentication (3LO) — OAuth 2.0 authorization code flow when Amazon Quick needs to act on behalf of individual users. Each user authenticates with the external service through their own identity.
- Service authentication (2LO) — Client credentials flow for system-to-system calls. Ideal for automations, scheduled workflows, and unattended operations where no user interaction is needed.
- No authentication — For public or demo MCP servers only.
This workshop focuses on 2LO service authentication using Amazon Cognito as the OAuth 2.0 authorization server a pattern you can replicate for any identity provider.
Infrastructure Overhead
Running your own MCP server means managing hosting, scaling, uptime, and security, before you have written a single tool definition. For many teams, this overhead is a blocker.
Amazon Bedrock AgentCore Runtime eliminates this. It is a fully managed serverless runtime specifically designed for MCP servers. You write your tool definitions, deploy your code using the
bedrock-agentcore-starter-toolkit CLI, and AgentCore Runtime handles the rest — no Docker, no Kubernetes, no servers to manage.Existing APIs Go Unused
Many teams already have perfectly good business logic running as AWS Lambda functions. They do not want to rewrite anything they just want those Lambda functions to be accessible to AI agents.
Amazon Bedrock AgentCore Gateway solves this. It wraps your existing Lambda functions and exposes them as MCP tools automatically. You define tool schemas (name, description, input parameters), and Gateway handles the MCP protocol, authentication, and routing. Your Lambda functions do not change at all.
Repetitive Work for ISVs
If you are a software vendor, you face a particularly painful version of this problem. Every customer who wants to use your product inside their AI platform requires a custom integration. Without a standard protocol, you are building and maintaining N integrations for N customers. With MCP, you build one integration — a single MCP server that exposes your product's capabilities — and every Amazon Quick customer can use it.

What Is Amazon Quick and Why Does It Need MCP?
Amazon Quick is your organization's agentic AI teammate. It is not just a chatbot or a dashboard it is a platform where AI agents can analyze data, search enterprise knowledge, run automated workflows, and take actions across your business systems. Users interact with it through natural language, and the AI figures out which tools to invoke, in what order, to get the job done.
The key word is tools. An AI agent in Amazon Quick is only as capable as the tools it has access to. Without tools, it can answer questions based on what it knows. With tools, it can:
- Query your HR system for an employee's leave balance
- Submit a timesheet on behalf of a user
- Create a Jira ticket, update a Salesforce record, or send a Slack message
- Pull payroll data, org chart information, or benefits enrollment status
- Run any action exposed by any system that has an API
MCP is the mechanism that makes this possible at scale. Instead of Amazon Quick needing a custom connector for every possible system, MCP provides a standard protocol. Any system that exposes an MCP server can be connected to Amazon Quick — and the AI agents inside Quick can immediately discover and use the tools that server exposes.
When Amazon Quick connects to an MCP server, it performs an initialization handshake: it sends its supported protocol version and capabilities, receives the server's capabilities in return, and then lists all available tools. This dynamic discovery means you never have to manually register individual tools in Quick. The server tells Quick what it can do, and Quick makes those capabilities available to AI agents automatically.
Workshop Overview
This workshop is structured as a progressive learning journey, following Paulo, a Senior AI Engineer at Any Company — a technology services firm. Paulo has been tasked with extending Amazon Quick's AI capabilities by integrating external data sources and tools through MCP servers. His organization uses multiple platforms: Notion for documentation, Linear for project tracking, Atlassian for development workflows, and a suite of internal HR systems.
Paulo's challenge is representative of what most enterprise teams face: a sprawling ecosystem of tools, no standard integration layer, and a mandate to make AI agents actually useful across all of them.
The workshop is organized into five modules:
| Module | What You Do | Time |
|---|---|---|
| Module 1 | Connect a pre-deployed remote MCP server to Amazon Quick | ~15 min |
| Module 2 | Build and deploy a custom MCP server to AgentCore Runtime | ~25 min |
| Module 3 | MCPify existing Lambda functions with AgentCore Gateway | ~20 min |
| Module 4 | Connect ISV MCP servers (Atlassian, Asana, Monday.com) | ~15 min |
| Module 5 | Explore Amazon Quick APIs for administration (optional) | ~30 min |
Getting Started
Before diving into the modules, the workshop walks you through environment setup. All workshop resources must be deployed in the same AWS region us-east-1 (US East - N. Virginia) is recommended, with us-west-2 (US West - Oregon) as an alternative.
Prerequisites:
- Amazon Quick Professional subscription
- Amazon Quick user with Author or higher permissions to create action connectors
- AWS account with SageMaker Studio pre-configured (provided at AWS events)
If you are attending an AWS-hosted event, your temporary account comes pre-configured with SageMaker Studio, pre-deployed CloudFormation stacks, IAM roles, and networking. Everything you need is already provisioned.
Module 1 — Integrate a Remote MCP Server into Amazon Quick
The first module is the most accessible entry point. Rather than building anything from scratch, you connect to a pre-deployed remote MCP server that was set up as part of the workshop infrastructure.
What the pre-deployed server does: It is a simple MCP server hosted on Amazon Bedrock AgentCore Gateway, backed by Lambda functions that perform CRUD operations against an S3 bucket. It uses 2LO authentication with Amazon Cognito as the OAuth 2.0 authorization server.
Why this matters: This module teaches you the consumer side of MCP integration how to connect Amazon Quick to any remote MCP server, whether it was built by you, by an ISV, or by a third party. The steps are the same regardless of what the server does.
Step-by-step walkthrough:
- Navigate to Amazon Quick in the AWS Console → Integrations → Actions
- Click the Model Context Protocol tile to create a new MCP integration
- Retrieve the MCP endpoint URL, Client ID, Client Secret, and Token URL from the CloudFormation stack outputs
- Configure 2LO service authentication in the Quick console
- Watch as Amazon Quick automatically authenticates, connects, and discovers the available tools
- Optionally share the integration with other users or groups in your organization
- Test the tools directly from the Quick console — no code required
Understanding 2LO vs 3LO authentication:
Two-Legged OAuth (2LO) is system-to-system authentication where the application authenticates directly with the authorization server using client credentials, without requiring user interaction. This makes it ideal for unattended operations like automations and scheduled tasks. Three-Legged OAuth (3LO) involves the end user in the authentication flow, requiring them to log in through the external service's identity provider. This workshop uses 2LO.
Key insight: When Amazon Quick connects to an MCP server, it performs a structured initialization sequence. The client sends an initialize request, the server responds with its capabilities and available tools, and the client sends an initialized notification to signal readiness. This handshake enables dynamic tool discovery you see the tools appear in the Quick console automatically.

Module 2 — Build and Deploy a Custom MCP Server Using Bedrock AgentCore Runtime
This is the core module for ISVs and enterprise teams who need to build a new MCP server from scratch. It answers the question: I have APIs. How do I wrap them as MCP tools and make them available to Amazon Quick?
The answer: Build an MCP server using
fastmcp, deploy it to Amazon Bedrock AgentCore Runtime, and connect it to Amazon Quick via OAuth.Why AgentCore Runtime? It is a fully managed serverless runtime specifically designed for MCP servers. You do not need Docker, Kubernetes, or any infrastructure management. You write your MCP server code, use the
bedrock-agentcore-starter-toolkit CLI to deploy it, and AgentCore Runtime handles hosting, scaling, and availability.The architecture:
1
2
3
Amazon Quick ──OAuth──▶ Cognito ──JWT──▶ AgentCore Runtime ──▶ Your MCP Server
(client_credentials) (domain + (validates JWT) (your API tools)
scope + secret)What you build — an HR system MCP server with 5 tools:
| Tool | What It Does | Example Amazon Quick Prompt |
|---|---|---|
get_employee_info | Retrieve complete employee details | "Show me details for employee EMP001" |
check_leave_balance | Query remaining vacation, sick, and personal days | "How many vacation days do I have left?" |
create_leave_request | Submit employee leave requests | "Request time off from March 1–5" |
update_employee_record | Modify employee information | "Update Alice's email to alice.new@company.com" |
create_support_ticket | Create IT/HR support tickets | "Create a support ticket for VPN issues" |
The notebook walks you through 9 steps:
- Install dependencies (
fastmcp,boto3,mcp,bedrock-agentcore-starter-toolkit) - Set up Cognito create a User Pool, domain, resource server with scope, and app client with secret
- Write the MCP server code define each tool using
fastmcpdecorators - Deploy to AgentCore Runtime using the starter toolkit CLI (~3–5 minutes)
- Store credentials in SSM Parameter Store and Secrets Manager
- Test list all 5 tools to confirm they are discoverable
- Test invoke all 5 tools with sample data to confirm end-to-end functionality
- Print the 4 connection values needed for Amazon Quick: Gateway URL, Client ID, Client Secret, Token URL
- Connect to Amazon Quick and test through natural language
Why this pattern is powerful for ISVs: You define your tools once. You deploy to a stable endpoint. Every Amazon Quick customer can connect to your MCP server using the same integration pattern no custom connectors, no per-customer engineering work. One MCP server supports all your customers.
Why this pattern is powerful for enterprises: Your internal systems HR, CRM, ERP, ticketing can be wrapped as MCP tools and made available to AI agents in Amazon Quick. Users interact with those systems through natural language without ever leaving the Quick interface.
Important operational note: Each MCP operation has a fixed 300-second timeout. Design your tool implementations to complete within this limit. Operations that exceed it fail with HTTP 424.
Estimated time: ~25 minutes

Module 3 — Build Your MCP Server Using Bedrock AgentCore Gateway
This module addresses a different starting point: I already have APIs running as AWS Lambda functions. I do not want to build an MCP server from scratch. How do I expose my Lambdas to Amazon Quick?
The answer: Amazon Bedrock AgentCore Gateway.
AgentCore Gateway sits between Amazon Quick and your Lambda functions. You define tool schemas name, description, input parameters and Gateway handles everything else: the MCP protocol, inbound authentication from Quick, outbound IAM-based invocation of your Lambdas. Your Lambda functions do not change at all.
The architecture:
1
2
3
4
┌──▶ hr-gw-get-payroll
Amazon Quick ──OAuth──▶ AgentCore Gateway ──IAM──┼──▶ hr-gw-get-org-chart
(MCP client) (MCP server) ├──▶ hr-gw-submit-timesheet
└──▶ hr-gw-get-benefitsWhen to use Gateway vs Runtime:
| Scenario | Use |
|---|---|
| You have existing APIs on Lambda and want to MCPify them | AgentCore Gateway |
| You need to build a new MCP server with custom logic | AgentCore Runtime |
What you build — 4 Lambda-backed MCP tools:
| Tool | Lambda Function | What It Does | Example Amazon Quick Prompt |
|---|---|---|---|
get_payroll_info | hr-gw-get-payroll | Retrieve salary and compensation data | "What's the salary for EMP001?" |
get_org_chart | hr-gw-get-org-chart | Query reporting structure and direct reports | "Who reports to Alice Johnson?" |
submit_timesheet | hr-gw-submit-timesheet | Submit weekly timesheet hours | "Log 40 hours for this week" |
get_benefits_summary | hr-gw-get-benefits | View employee benefits enrollment | "Show me my benefits package" |
The notebook walks you through 8 steps:
- Install dependencies (
boto3,requests) - Create the 4 HR Lambda functions (in your real scenario, these already exist skip this step and point Gateway at your existing Lambda ARNs)
- Create an IAM role for Gateway to assume when invoking your Lambdas
- Set up Cognito for inbound OAuth authentication from Amazon Quick
- Create an AgentCore Gateway with the Cognito authorizer
- Add each Lambda as a Gateway target with its MCP tool schema
- Test tools through the Gateway — confirm the full auth chain: OAuth token → Gateway validates JWT → IAM role → Lambda invocation
- Print connection details for Amazon Quick and connect
Key insight: The tool schema you define in Gateway is what Amazon Quick sees. A well-written tool description clear name, detailed description, well-typed input parameters directly improves how accurately the AI agent selects and invokes your tool. The schema is not just configuration; it is the contract between your API and the AI.
Estimated time: ~20 minutes

Module 4 — Integrate an ISV MCP Server into Amazon Quick (Optional)
Modules 2 and 3 teach you how to build MCP servers. This module teaches you how to connect to MCP servers that already exist specifically, servers published by Independent Software Vendors (ISVs).
The growing MCP ecosystem means that many popular SaaS products now publish their own MCP servers. This module walks through three real-world examples:
Atlassian (Jira & Confluence)
Connect Amazon Quick to Atlassian's MCP server to enable AI agents to query Jira issues, update ticket statuses, search Confluence documentation, and manage project workflows — all through natural language in Quick. Uses 3LO OAuth so each user authenticates with their own Atlassian identity.
Asana
Asana's MCP server uses 3LO (Three-Legged OAuth), which requires each user to authenticate with Asana through their own identity. The module walks through creating an Asana app, configuring OAuth redirect URIs, and setting up the integration in Amazon Quick. Once connected, users can create tasks, update projects, and manage team workflows from Quick.

Important for 3LO integrations: Some identity providers block OAuth redirects unless the redirect URI is explicitly allowlisted. If your OAuth setup fails during integration creation, confirm that your OAuth client app allowlists the Amazon Quick redirect URI for each AWS Region where your customers use Amazon Quick:
1
2
3
4
https://us-east-1.quicksight.aws.amazon.com/sn/oauthcallback
https://us-west-2.quicksight.aws.amazon.com/sn/oauthcallback
https://ap-southeast-2.quicksight.aws.amazon.com/sn/oauthcallback
https://eu-west-1.quicksight.aws.amazon.com/sn/oauthcallbackMonday.com
Monday.com's MCP server is available at
https://mcp.monday.com/sse. The module covers creating the integration, configuring 3LO authentication, and testing it with real prompts:- "Create a Monday.com board called 'Campaign Launch' with Status, Owner, and Due Date columns"
- "Add a task assigned to me with a due date of next Friday"
- "Show me all items in the Campaign Launch board"
- "Update the status of that item to In Progress"
Prerequisites for this module:
- Amazon Quick Professional subscription
- Amazon Quick Author-level permissions or higher for action connectors
- Active accounts with the relevant ISV (Atlassian, Asana, or Monday.com)
Why this module matters: It demonstrates that MCP is not just a protocol for custom integrations it is an ecosystem. As more ISVs publish MCP servers, the value of Amazon Quick grows automatically. Any new MCP server that appears in the ecosystem is immediately connectable to Quick using the same steps you learned in Module 1.

Module 5 — Leveraging Amazon Quick APIs for Administration (Optional)
This module steps outside the MCP scope and into Amazon Quick's own APIs. It is designed for administrators and developers who want to programmatically manage their Amazon Quick environment — automating governance tasks, auditing integrations, managing users, and monitoring workflows.
The module provides four Python notebooks running in SageMaker Studio, each demonstrating a different area of the QuickSight/Quick API via
boto3:Action Connectors API (quick-api-action-connectors.ipynb)
Programmatically list, describe, filter, and analyze all action connectors in your Amazon Quick account. Useful for auditing which external systems are connected, identifying unused integrations, and generating compliance reports. Covers pagination, filtering by connector type, and exporting connector metadata to JSON.
Flows API (quick-api-flows.ipynb)
Manage Amazon Quick Flows — AI-powered automated workflows for data processing — through the API. List all flows, filter by status, analyze flow configurations, and search for specific automation patterns. Useful for administrators who need visibility into what automations are running across the organization.
Role Memberships API (quick-api-role-memberships.ipynb)
Query and analyze user access control across your Amazon Quick environment. Understand which users have which roles (READER, AUTHOR, ADMIN, READER_PRO), identify access patterns, and generate reports for compliance and governance purposes.
Users API (quick-api-users.ipynb)
Manage user accounts programmatically. List users, analyze account status, and generate user reports. Useful for onboarding automation, offboarding workflows, and periodic access reviews.
Why this module matters: As your Amazon Quick environment grows — more integrations, more users, more automations — manual administration through the console becomes impractical. These API patterns give you the building blocks for automated governance: scheduled audits, automated onboarding/offboarding, integration health monitoring, and compliance reporting.
Conclusion
MCP is becoming the standard integration layer between AI agents and enterprise systems. This workshop gives you the complete picture from consuming existing MCP servers to building your own, from managed runtime deployments to Gateway-based Lambda wrapping, from custom enterprise integrations to connecting popular ISV tools.
Here is what you walk away with:
- A repeatable integration pattern — define tools once, publish a stable endpoint, support all customers with one integration
- Two production-ready deployment options — AgentCore Runtime for new MCP servers, AgentCore Gateway for existing Lambda APIs
- A working understanding of MCP authentication — Cognito OAuth, 2LO vs 3LO, JWT validation, OAuth redirect allowlisting
- Hands-on experience with the Amazon Quick console — connecting MCP servers, discovering tools, testing integrations, sharing with users
- Practical API patterns for administering your Amazon Quick environment at scale
Whether you are an ISV looking to make your SaaS product available inside Amazon Quick, an enterprise IT team connecting HR, CRM, or ERP systems to AI workflows, or a developer building custom solutions for specific business needs — this workshop gives you the blueprint.
A few operational principles to carry forward:
- Start with a small set of high-value tools the operations your customers use most
- Design each tool call to complete within the 300-second timeout limit
- Document the exact endpoint and authentication settings your customers must use
- Treat tool names and schemas as a contract coordinate changes with your customers
- Add logging, throttling, and tenant-aware observability from day one
Next Steps
- Access the workshop in AWS Workshop Studiolaunch it in us-east-1 and open SageMaker JupyterLab
- Start with Module 1 connect the pre-deployed MCP server to Amazon Quick to understand the consumer experience
- Choose your build path:
HR_MCP_Workshop.ipynbbuild a custom MCP server and deploy to AgentCore Runtime (~25 min)HR_Gateway_Workshop.ipynbMCPify existing Lambda functions with AgentCore Gateway (~20 min)
- Explore ISV integrations connect Atlassian, Asana, or Monday.com if you have accounts
- Adapt the patterns to your APIs replace the HR examples with your own services; the deployment pattern is identical
- Validate your server using the MCP Inspector before connecting to Amazon Quick if it works with the Inspector, it is protocol-compliant and ready for Quick integration
Further reading:
- Amazon Quick MCP Integration documentation
- Amazon Quick User Guide
- Amazon Bedrock AgentCore Runtime documentation
- Amazon Bedrock AgentCore Gateway documentation
- Model Context Protocol specification
- Deploying MCP servers on AWS — GitHub repository
This workshop was developed by the Amazon Quick team. Questions or feedback? Connect with the team through the AWS Builder Center.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article